From walters at redhat.com Wed Aug 1 00:13:35 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 31 Jul 2007 20:13:35 -0400 Subject: f8 desktop livecd In-Reply-To: <46AD9EBD.3030804@fedoraproject.org> References: <1185552270.3323.58.camel@neutron.verbum.private> <46AB2386.4060606@fedoraproject.org> <1185759043.3422.13.camel@neutron.verbum.private> <46AD9EBD.3030804@fedoraproject.org> Message-ID: <1185927215.14236.28.camel@neutron.verbum.private> On Mon, 2007-07-30 at 13:48 +0530, Rahul Sundaram wrote: > Colin Walters wrote: > > > > > Right, though ideally this isn't a big formal project, just a place > > where we can tweak some defaults or the like. I think a lot depends on > > how much time is spent on it, but agreed that at this point it seems > > clear that we need to differentiate things better on the website at a > > minimum. Not sure what that text should say yet though... > > When we say the Live images are desktop focused, what do we mean by > that? Configuration changes like network manager by default, subset of > Fedora that is good for desktop usage or something else? Ok. In this discussion, one thing I'd like to keep in mind is that the technical fact that it's a "Live CD" or "Live Media" is not the interesting part. What is interesting is that it makes some attempt at choosing a target audience and defaults+tweaks for that target[1]. Maybe this means it's a spin. As Fedora seems to be going in the direction of making it easy for people to derive from Fedora, we could start to think in those terms. Setting aside what to call it - I think the goal is to make a downloadable image that can be used as a start for: 1) Personal laptop internet terminal 2) Web developer workstation 3) Locked-down/managed lab terminal Now, I think that 2) is basically a larger set of packages (wireshark, eclipse, icedtea, ruby, etc.) on top of 1). We should make it extremely easy to turn 1) into 2), because honestly I think that's where a lot of Fedora market share currently lies. 3) is interesting but those people can use the tools to make exactly what they want. Even 1) is pretty vague, but it's at least an attempt at something. It gives us at least a guideline for figuring out what to include. For example, it makes it pretty obvious that packages like autofs and wireshark shouldn't be in the default package set. [1] Unlike the DVD, which is a massive collection of software with lots of duplicated/unnecessary functionality that makes you choose mid-install (when you've already downloaded all of it) what to copy to your drive. From davidz at redhat.com Wed Aug 1 18:00:39 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 01 Aug 2007 14:00:39 -0400 Subject: f8 desktop livecd In-Reply-To: <1185552270.3323.58.camel@neutron.verbum.private> References: <1185552270.3323.58.camel@neutron.verbum.private> Message-ID: <1185991239.2822.45.camel@oneill.fubar.dk> Hi, Sorry for the lag, On Fri, 2007-07-27 at 12:04 -0400, Colin Walters wrote: > Some people may not know that in Fedora 7, there was a difference > between the DVD and the Live CD. What happened is (as far as I > understand it) David Zeuthen took a look at things, and exercised a > bit of editorial control by using the kickstart file - ship > NetworkManager enabled by default, for example. This is exactly what > Fedora as a desktop needs; a place for people who care about the > experience as a desktop to do those quick fixes that may be hard to > change in the Fedora base. Right. In fact, the Fedora Core 6 live cd had an even more narrow focus: only desktop users. I mean, just take a look at the delta between the F6 and F7 live CD: http://www.redhat.com/archives/fedora-devel-list/2006-December/msg00469.html Notable differences - FC6 live CD was not installable; F7 live cd was - FC6 live CD included more, uh, apps with a desktop focus that were not in the F7 live CD (due to lack of disc space) - Beagle, F-Spot, Inkscape, VPN tools (vpnc, openvpn) - FC6 live CD omitted lots of things I don't think belongs in a default desktop install. Notably F7 live CD includes many of these things - things like autofs, all of system-config-* I was told at the time that "people except these things in a Fedora install". And I think that's the problem: that the target group of the F7 live cd is assumed to be any Fedora user instead of catering to desktop/laptop users. See below for more discussion. Some explicit goals from the FC6 live CD were carried over though - Universal Local support; e.g. abandon the "what languages do you need?" question during install. This includes - Include enough fonts to have near 100% coverage of all the web pages in the world (http://wikipedia.org/ is a good test) - Include all input methods; in fact, thanks to Warren Togami and others this was refined in F7 live cd to only start the Input Method applet if the locale needs it (e.g. avoid starting it in e.g. en_US and da_DK) and in addition the F7 live cd is now installable which was a very big thing. > So this mail is just to say that this project exists (and I know a lot > of people didn't know about the difference), and will move forward. For > Fedora 8, it would make sense to more prominently distinguish this > version as the Desktop version. Right, I agree. The first thing that the Fedora project needs to address is making it easy for users to figure out what to download. Right now it's very confusing; just have a look at http://fedoraproject.org/get-fedora.html Instead, what we want is something like this http://www.ubuntu.com/getubuntu/download that actually guides people in downloading the right version. It could look like this Fedora Desktop The perfect distribution tailored for both novice and seasoned desktop/laptop users. Featuring a network-less single-CD dead-simple install with a tasteful set of defaults chosen for you, you can always configure the system to your liking post-install. Fedora KDE (put something here) Fedora Universe Want to install a headless server or to an exotic system? Want to hand-tune the packages getting installed? Want to harness the power of scripting and fine-tuning system configuration? Want to do a network install? The Fedora Server is for you. It features both networked installs and updates. Perfect for the picky experts. So we tell everyone to use "Fedora Desktop" instead. What's missing here is the upgrade story and our current story is "use anaconda to upgrade" which I think is pretty lame. We're asking people to go to d.fp.org (which already sucks) and make them download an ISO. Clearly, technical problems aside, we simply *need* to have the package updater UI say "Hey, you're running Fedora N and Fedora N+1 is out. Press here to upgrade". How we solve that from a technical point of view, I don't care, but I _know_ it's technical feasible. Here's two suggestions - "Just" fix yum, rpm and the way we do packaging / QA to actually make updating a live Fedora from version N to N+1 work. At least concede "it's a bug if it doesn't work" instead of saying "oh, that may not work; the official way is to use anaconda". - Compute what RPM's are needed; download those. Provide a simple boot image that takes these RPM's and updates the base system. Poke grub.conf to boot into this. Ask user to reboot to complete the upgrade. System reboots into update image that simply updates the system. No user interaction. When update is complete, system reboots. Done. I have a lot of thoughts about technical details and what set of packages should (and shouldn't) go on the Fedora Desktop Live CD. For example, I mean, a desktop system clearly don't need junk like system-config-keyboard or system-config-language since we don't care about the console. People who care about that stuff can install it later. So the main problem here is (lack of) *direction* and *messaging*. It's a social problem. In other words, the Fedora Project (thus, the board), need to say "OK, we're actually doing a targeted Fedora Desktop product and people not using it for desktop/laptop can use the old 'Fedora Universe' way of doing things.". Until I see such leadership coming from the board I'm not sure it's worth messing around with kickstart files at all? We, the people working on the Fedora Desktop, have this great chance to actually do a really good desktop distro. But as long as people expect "Fedora Live Media" to work in e.g. server use cases (as I argue they may do today, mainly due to bad messaging), it's just a waste of time IMNSHO. We need direction and razor sharp focus. We need the backing of the Fedora project and board to recognize that we're going to target *only* desktop users with the live media. We need to communicate that "Fedora Live Media" is *the* way to install the Desktop or KDE flavors of Fedora. It's about direction and messaging. Fix that and we can do good stuff. David ps. Sorry if this mails came across as a rant. From walters at redhat.com Wed Aug 1 18:43:13 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 01 Aug 2007 14:43:13 -0400 Subject: f8 desktop livecd In-Reply-To: <1185991239.2822.45.camel@oneill.fubar.dk> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> Message-ID: <1185993793.3123.31.camel@neutron.verbum.private> On Wed, 2007-08-01 at 14:00 -0400, David Zeuthen wrote: > In other words, the Fedora Project (thus, the board), need to say "OK, > we're actually doing a targeted Fedora Desktop product and people not > using it for desktop/laptop can use the old 'Fedora Universe' way of > doing things.". Until I see such leadership coming from the board I'm > not sure it's worth messing around with kickstart files at all? I don't think we need to wait for leadership necessarily, if there is interest in it. Let's make it work. If it does, then we can jump through whatever red tape is necessary. > We, the people working on the Fedora Desktop, have this great chance to > actually do a really good desktop distro. Right, because it's not actually that hard, as you (and whoever else that hacked on the livecd stuff) proved. It's just being willing to sit down and polish. > But as long as people expect > "Fedora Live Media" to work in e.g. server use cases (as I argue they > may do today, mainly due to bad messaging), it's just a waste of time Totally agree. Ok. Here's my suggestion. We call this "Fedora Personal Laptop". Skip the word "Desktop" because it means too many different things. Personal Laptop is defined as targeting roughly the same base set of functionality that one might expect to find after purchasing a mainstream consumer laptop from Dell, Apple, HP, etc. It is very explicitly *NOT* defined as a "Linux distribution" or "Fedora", because the first definition is and always has been meaningless, and the second is just vacuous/self-referential. Does this mean Personal Laptop is actually defined as chasing the tail of competitors? Yes, it does. Is there something wrong with that? Well, it's a lot better than just shipping a gigantic DVD or a mishmash of whatever random package developers thought needs to be in "Fedora". From skvidal at fedoraproject.org Wed Aug 1 18:45:57 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 01 Aug 2007 14:45:57 -0400 Subject: f8 desktop livecd In-Reply-To: <1185993793.3123.31.camel@neutron.verbum.private> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> Message-ID: <1185993957.998.57.camel@cutter> On Wed, 2007-08-01 at 14:43 -0400, Colin Walters wrote: > Does this mean Personal Laptop is actually defined as chasing the tail > of competitors? Yes, it does. Is there something wrong with that? > Well, it's a lot better than just shipping a gigantic DVD or a mishmash > of whatever random package developers thought needs to be in "Fedora". As important as your goals are, denigrating the people who put the whole distribution together with this last remark is unnecessary and unhelpful. There's no need for divisiveness. What you're working on does not preclude the work that makes it possible for you to do that. -sv From jkeating at redhat.com Wed Aug 1 18:46:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 1 Aug 2007 14:46:35 -0400 Subject: f8 desktop livecd In-Reply-To: <1185993793.3123.31.camel@neutron.verbum.private> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> Message-ID: <20070801144635.5c2c361c@localhost.localdomain> On Wed, 01 Aug 2007 14:43:13 -0400 Colin Walters wrote: > Ok. Here's my suggestion. We call this "Fedora Personal Laptop". > Skip the word "Desktop" because it means too many different things. > > Personal Laptop is defined as targeting roughly the same base set of > functionality that one might expect to find after purchasing a > mainstream consumer laptop from Dell, Apple, HP, etc. > > It is very explicitly *NOT* defined as a "Linux distribution" or > "Fedora", because the first definition is and always has been > meaningless, and the second is just vacuous/self-referential. > > Does this mean Personal Laptop is actually defined as chasing the tail > of competitors? Yes, it does. Is there something wrong with that? > Well, it's a lot better than just shipping a gigantic DVD or a > mishmash of whatever random package developers thought needs to be in > "Fedora". I would love to see something like this, even by Test2 if possible. I'd even be willing to make our 'default' Live image we ship this, instead of a Live version of the "Fedora" spin (whatever the heck that's supposed to mean). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From walters at redhat.com Wed Aug 1 18:52:24 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 01 Aug 2007 14:52:24 -0400 Subject: f8 desktop livecd In-Reply-To: <1185993957.998.57.camel@cutter> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <1185993957.998.57.camel@cutter> Message-ID: <1185994344.3123.34.camel@neutron.verbum.private> On Wed, 2007-08-01 at 14:45 -0400, seth vidal wrote: > On Wed, 2007-08-01 at 14:43 -0400, Colin Walters wrote: > > > Does this mean Personal Laptop is actually defined as chasing the tail > > of competitors? Yes, it does. Is there something wrong with that? > > Well, it's a lot better than just shipping a gigantic DVD or a mishmash > > of whatever random package developers thought needs to be in "Fedora". > > As important as your goals are, denigrating the people who put the whole > distribution together with this last remark is unnecessary and > unhelpful. You are right, and I apologize! It was not just unnecessary but wrong. I got too worked up into things for sure. From sundaram at fedoraproject.org Wed Aug 1 18:59:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Aug 2007 00:29:20 +0530 Subject: f8 desktop livecd In-Reply-To: <1185991239.2822.45.camel@oneill.fubar.dk> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> Message-ID: <46B0D808.9090907@fedoraproject.org> David Zeuthen wrote: > > In other words, the Fedora Project (thus, the board), need to say "OK, > we're actually doing a targeted Fedora Desktop product and people not > using it for desktop/laptop can use the old 'Fedora Universe' way of > doing things.". Until I see such leadership coming from the board I'm > not sure it's worth messing around with kickstart files at all? I am not sure if you have seen the the long thread on fedora advisory board list on what the target market is. Take a look at http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/2821 There is also a article at http://lwn.net/SubscriberLink/242965/c8ef393b828b04e8/ I would highly recommend writing down a proposal and send to the advisory board list. If you or anyone as a team want to lead this effort, it is likely the board will accept that.' Waiting for this to happen on its own somehow is unlikely to work. Rahul From walters at redhat.com Wed Aug 1 19:03:25 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 01 Aug 2007 15:03:25 -0400 Subject: f8 desktop livecd In-Reply-To: <20070801144635.5c2c361c@localhost.localdomain> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> Message-ID: <1185995005.3123.43.camel@neutron.verbum.private> On Wed, 2007-08-01 at 14:46 -0400, Jesse Keating wrote: > On Wed, 01 Aug 2007 14:43:13 -0400 > Colin Walters wrote: > > > Ok. Here's my suggestion. We call this "Fedora Personal Laptop". > > Skip the word "Desktop" because it means too many different things. > > > > Personal Laptop is defined as targeting roughly the same base set of > > functionality that one might expect to find after purchasing a > > mainstream consumer laptop from Dell, Apple, HP, etc. > > > > It is very explicitly *NOT* defined as a "Linux distribution" or > > "Fedora", because the first definition is and always has been > > meaningless, and the second is just vacuous/self-referential. > > > > Does this mean Personal Laptop is actually defined as chasing the tail > > of competitors? Yes, it does. Is there something wrong with that? > > Well, it's a lot better than just shipping a gigantic DVD or a > > mishmash of whatever random package developers thought needs to be in > > "Fedora". > > I would love to see something like this, even by Test2 if possible. > I'd even be willing to make our 'default' Live image we ship this, > instead of a Live version of the "Fedora" spin (whatever the heck > that's supposed to mean). [walters at neutron livecd]$ git status # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # renamed: config/livecd-fedora-desktop.ks -> config/livecd-fedora-personal.ks # For now, in here: http://submind.verbum.org/~walters/livecd.git/ I haven't looked whether the package set is sane for fedora-personal.ks. I did verify it boots. Basically I just did some infrastructure work so that I could create an online-desktop livecd without creating yet another fork of a big kickstart file. It's a start! An immediate interesting task for the fedora-personal.ks would be seeing how hard it would be to fit say OpenOffice, now that we know we can drop things like sendmail, etc. From mclasen at redhat.com Wed Aug 1 19:01:26 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 01 Aug 2007 15:01:26 -0400 Subject: f8 desktop livecd In-Reply-To: <46B0D808.9090907@fedoraproject.org> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <46B0D808.9090907@fedoraproject.org> Message-ID: <1185994886.3330.4.camel@dhcp83-186.boston.redhat.com> On Thu, 2007-08-02 at 00:29 +0530, Rahul Sundaram wrote: > David Zeuthen wrote: > > > > > In other words, the Fedora Project (thus, the board), need to say "OK, > > we're actually doing a targeted Fedora Desktop product and people not > > using it for desktop/laptop can use the old 'Fedora Universe' way of > > doing things.". Until I see such leadership coming from the board I'm > > not sure it's worth messing around with kickstart files at all? > > I am not sure if you have seen the the long thread on fedora advisory > board list on what the target market is. > > Take a look at > http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/2821 > > There is also a article at > http://lwn.net/SubscriberLink/242965/c8ef393b828b04e8/ > > I would highly recommend writing down a proposal and send to the > advisory board list. If you or anyone as a team want to lead this > effort, it is likely the board will accept that.' > > Waiting for this to happen on its own somehow is unlikely to work. There is no need to wait for anything, as Colin said. Or to apply for approval to any superiors. We just need to do it. And we will. From sundaram at fedoraproject.org Wed Aug 1 19:09:03 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Aug 2007 00:39:03 +0530 Subject: f8 desktop livecd In-Reply-To: <1185927215.14236.28.camel@neutron.verbum.private> References: <1185552270.3323.58.camel@neutron.verbum.private> <46AB2386.4060606@fedoraproject.org> <1185759043.3422.13.camel@neutron.verbum.private> <46AD9EBD.3030804@fedoraproject.org> <1185927215.14236.28.camel@neutron.verbum.private> Message-ID: <46B0DA4F.5030309@fedoraproject.org> Colin Walters wrote: > > Maybe this means it's a spin. As Fedora seems to be going in the > direction of making it easy for people to derive from Fedora, we could > start to think in those terms. Right, the Fedora KDE live images are the Fedora KDE spin and it is messaged as such. Since we do multilib the x86_64 images happen to be more than CD size which I think we should avoid but that's another topic. > Setting aside what to call it - I think the goal is to make a > downloadable image that can be used as a start for: > > 1) Personal laptop internet terminal > 2) Web developer workstation > 3) Locked-down/managed lab terminal > > Now, I think that 2) is basically a larger set of packages (wireshark, > eclipse, icedtea, ruby, etc.) on top of 1). We should make it extremely > easy to turn 1) into 2), because honestly I think that's where a lot of > Fedora market share currently lies. > 3) is interesting but those people can use the tools to make exactly > what they want. I think 1) is provided by the Fedora live images or alteast close to it. There has been some discussions from people who have installed from the live images but want the same setup as the default selection in the DVD and by that they probably want to do 2). I am not sure how we are going to do 3) well. There is Sabayon and Pessulus in GNOME and Kiosk in KDE but they don't talk to each other and isn't really system wide. Some folks have been asking for similar software that they can use on internet cafe's. Atleast here some cafe's are migrating to Linux/Fedora because Microsoft has started enforcing their licensing and some businesses simple cannot afford the cost. That is a sort of a niche market that is growing. Rahul From sundaram at fedoraproject.org Wed Aug 1 19:16:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Aug 2007 00:46:36 +0530 Subject: f8 desktop livecd In-Reply-To: <1185994886.3330.4.camel@dhcp83-186.boston.redhat.com> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <46B0D808.9090907@fedoraproject.org> <1185994886.3330.4.camel@dhcp83-186.boston.redhat.com> Message-ID: <46B0DC14.9010404@fedoraproject.org> Matthias Clasen wrote: > There is no need to wait for anything, as Colin said. > Or to apply for approval to any superiors. > We just need to do it. > And we will. Talking to the board doesn't really equate to "approval to superiors". David Zuethen said he wanted the board to acknowledge that and I do think you need project wide support to do something like this efficiently instead of continuing to do something as a closed group. If you can just do it, more power to you but let people know what you have planned including positioning the live images as the desktop spin. Rahul From notting at redhat.com Wed Aug 1 19:24:20 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Aug 2007 15:24:20 -0400 Subject: f8 desktop livecd In-Reply-To: <1185995005.3123.43.camel@neutron.verbum.private> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> Message-ID: <20070801192420.GC26862@nostromo.devel.redhat.com> Colin Walters (walters at redhat.com) said: > An immediate interesting task for the fedora-personal.ks would be seeing > how hard it would be to fit say OpenOffice, now that we know we can drop > things like sendmail, etc. If you intend to keep to the 'single-image-for-all-languages' goal, and still have it fit on a CD... isn't going to happen. Bill From mclasen at redhat.com Wed Aug 1 19:23:50 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 01 Aug 2007 15:23:50 -0400 Subject: f8 desktop livecd In-Reply-To: <46B0DC14.9010404@fedoraproject.org> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <46B0D808.9090907@fedoraproject.org> <1185994886.3330.4.camel@dhcp83-186.boston.redhat.com> <46B0DC14.9010404@fedoraproject.org> Message-ID: <1185996230.3330.15.camel@dhcp83-186.boston.redhat.com> On Thu, 2007-08-02 at 00:46 +0530, Rahul Sundaram wrote: > Matthias Clasen wrote: > > There is no need to wait for anything, as Colin said. > > Or to apply for approval to any superiors. > > We just need to do it. > > And we will. > > Talking to the board doesn't really equate to "approval to superiors". > David Zuethen said he wanted the board to acknowledge that and I do > think you need project wide support to do something like this > efficiently instead of continuing to do something as a closed group. Just stop the "closed group" mantra, please. We are discussing this on a public mailing list. From sundaram at fedoraproject.org Wed Aug 1 19:33:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Aug 2007 01:03:09 +0530 Subject: f8 desktop livecd In-Reply-To: <1185996230.3330.15.camel@dhcp83-186.boston.redhat.com> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <46B0D808.9090907@fedoraproject.org> <1185994886.3330.4.camel@dhcp83-186.boston.redhat.com> <46B0DC14.9010404@fedoraproject.org> <1185996230.3330.15.camel@dhcp83-186.boston.redhat.com> Message-ID: <46B0DFF5.8010308@fedoraproject.org> Matthias Clasen wrote: > On Thu, 2007-08-02 at 00:46 +0530, Rahul Sundaram wrote: >> Matthias Clasen wrote: >>> There is no need to wait for anything, as Colin said. >>> Or to apply for approval to any superiors. >>> We just need to do it. >>> And we will. >> Talking to the board doesn't really equate to "approval to superiors". >> David Zuethen said he wanted the board to acknowledge that and I do >> think you need project wide support to do something like this >> efficiently instead of continuing to do something as a closed group. > > Just stop the "closed group" mantra, please. We are discussing this on a > public mailing list. Yes this is a public list and it is desktop specific and it was pretty much dead for a few releases. This is not a place to get project wide support. If desktop team is a SIG and acting in the open, I would able to find the list of members, lead etc but like I said before things have improved more than before. Rahul From caillon at redhat.com Wed Aug 1 20:05:07 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 01 Aug 2007 16:05:07 -0400 Subject: f8 desktop livecd In-Reply-To: <46B0DFF5.8010308@fedoraproject.org> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <46B0D808.9090907@fedoraproject.org> <1185994886.3330.4.camel@dhcp83-186.boston.redhat.com> <46B0DC14.9010404@fedoraproject.org> <1185996230.3330.15.camel@dhcp83-186.boston.redhat.com> <46B0DFF5.8010308@fedoraproject.org> Message-ID: <46B0E773.9050502@redhat.com> Rahul Sundaram wrote: > Matthias Clasen wrote: >> Just stop the "closed group" mantra, please. We are discussing this on a >> public mailing list. > > Yes this is a public list and it is desktop specific and it was pretty > much dead for a few releases. This is not a place to get project wide > support. Rahul, There are many contributors on this list, including non Red Hat employees, and several board members are keenly following threads here. > If desktop team is a SIG and acting in the open, I would able > to find the list of members, lead etc but like I said before things have > improved more than before. So in order to be open one needs to have a SIG? That means that countless "open" source projects really aren't because they don't have SIGs or list their full membership? Seriously. Stop. Adding false conflict only serves to harm the project as a whole. From sundaram at fedoraproject.org Wed Aug 1 20:15:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Aug 2007 01:45:16 +0530 Subject: f8 desktop livecd In-Reply-To: <46B0E773.9050502@redhat.com> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <46B0D808.9090907@fedoraproject.org> <1185994886.3330.4.camel@dhcp83-186.boston.redhat.com> <46B0DC14.9010404@fedoraproject.org> <1185996230.3330.15.camel@dhcp83-186.boston.redhat.com> <46B0DFF5.8010308@fedoraproject.org> <46B0E773.9050502@redhat.com> Message-ID: <46B0E9D4.1090104@fedoraproject.org> Christopher Aillon wrote: > Rahul Sundaram wrote: >> Matthias Clasen wrote: >>> Just stop the "closed group" mantra, please. We are discussing this on a >>> public mailing list. >> >> Yes this is a public list and it is desktop specific and it was pretty >> much dead for a few releases. This is not a place to get project wide >> support. > > Rahul, There are many contributors on this list, including non Red Hat > employees, and several board members are keenly following threads here. I don't understand the amount of resistance in following any process at all and providing feedback where it matters. If you want the board to do something, then communicate what you want to them. Is that a big deal? > So in order to be open one needs to have a SIG? Nope but in Fedora if there is a team working together on something it would be usually easy to atleast find out who the members are. How do I find out who the members are in the desktop team? Who is making the decisions and where are they making it in all the previous releases? A SIG or sub project is how people organize together in Fedora. All the work on the desktop in Fedora does goes without any visibility and I have already talked to various members about this problem in the past. Getting defensive is not going to solve it. You merely end up shooting the messenger. Rahul From caolanm at redhat.com Thu Aug 2 07:38:45 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 02 Aug 2007 08:38:45 +0100 Subject: f8 desktop livecd In-Reply-To: <1185995005.3123.43.camel@neutron.verbum.private> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> Message-ID: <1186040325.3239.3.camel@Nom> On Wed, 2007-08-01 at 15:03 -0400, Colin Walters wrote: > An immediate interesting task for the fedora-personal.ks would be seeing > how hard it would be to fit say OpenOffice, now that we know we can drop > things like sendmail, etc. Just looked at the ubuntu livecd recently, has OOo on it and the gimp, the ubuntu gimp doesn't ask anything during first install. So it might be neat for the livecd/personal cd to include pre-canned .gimp-2.2/.openoffice.org2 config directories for the livecd ~/home to avoid the very first-start up time hit/config questions for the livecds C. From drago01 at gmail.com Thu Aug 2 08:22:15 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 02 Aug 2007 10:22:15 +0200 Subject: f8 desktop livecd In-Reply-To: <1185993793.3123.31.camel@neutron.verbum.private> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> Message-ID: <46B19437.7040204@gmail.com> Colin Walters wrote: > Ok. Here's my suggestion. We call this "*Fedora Personal Laptop*". Skip > the word "Desktop" because it means too many different things. > > This is a awfull name. If you call it "Laptop" only people who use/have laptops will download and use it. But it should be targeted at _desktop_ users .. so whats wrong with the name desktop? You can do atleast s/Laptop/Desktop/ From ml at deadbabylon.de Thu Aug 2 10:14:53 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 2 Aug 2007 12:14:53 +0200 Subject: livecd hacking In-Reply-To: <1185920349.12650.4.camel@neutron.verbum.private> References: <1185920349.12650.4.camel@neutron.verbum.private> Message-ID: <20070802121453.1f16ad52@localhost.localdomain> Am Tue, 31 Jul 2007 18:19:09 -0400 schrieb Colin Walters : > I've done some work on the Live CD kickstart images, available here: > > http://submind.verbum.org/~walters/livecd.git/ > > (Until Jeremy returns from vacation and can review patches to be put > in the main livecd git repository) > > The most important change so far is to create > "livecd-desktop-minimal.ks" which is then used as a basis for: > > livecd-fedora-desktop.ks > livecd-fedora-kde.ks > livecd-online-desktop.ks > > Rather than each thing duplicating a lot of code for the livecd init > script, etc. > > The online-desktop is just a stub right now while I fix up some > issues, but I've booted the livecd-fedora-desktop successfully > (livecd-desktop-minimal.ks also boots...into twm! Retro.). > > Admittedly I haven't tested the KDE one, but moving forward this > unforking should help us to identify changes common between them which > seem like good candidates for comps or Fedora package changes. > > Sebastian, since you were the last person to touch the KDE bits, could > you have a look at these changes? livecd-fedora-kde.ks is working but installs too much more packages than the old config (and also some unwanted, eg. gnome-games). This is related to livecd-desktop-minimal.ks which includes more groups than the kde config. If the kde livecd should also use this config some groups should be removed. The size with livecd-desktop-minimal.ks is here (i386) 770 megs to 687 megs with the normal config. And some small note: I've had to run livecd-creator from inside the config directory so that it could find livecd-desktop-minimal.ks. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Aug 2 11:34:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 2 Aug 2007 07:34:53 -0400 Subject: f8 desktop livecd In-Reply-To: <1186040325.3239.3.camel@Nom> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> Message-ID: <20070802073453.793671ad@ender> On Thu, 02 Aug 2007 08:38:45 +0100 Caolan McNamara wrote: > Just looked at the ubuntu livecd recently, has OOo on it and the gimp, > the ubuntu gimp doesn't ask anything during first install. So it might > be neat for the livecd/personal cd to include > pre-canned .gimp-2.2/.openoffice.org2 config directories for the > livecd ~/home to avoid the very first-start up time hit/config > questions for the livecds As stated elsewhere, having all languages as a goal and having OO.org as a goal are in direct conflict. oo.org+translations is over 700 megs itself. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Thu Aug 2 11:40:11 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 02 Aug 2007 13:40:11 +0200 Subject: f8 desktop livecd In-Reply-To: <20070802073453.793671ad@ender> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> Message-ID: <46B1C29B.9010109@gmail.com> Jesse Keating wrote: > On Thu, 02 Aug 2007 08:38:45 +0100 > Caolan McNamara wrote: > > >> Just looked at the ubuntu livecd recently, has OOo on it and the gimp, >> the ubuntu gimp doesn't ask anything during first install. So it might >> be neat for the livecd/personal cd to include >> pre-canned .gimp-2.2/.openoffice.org2 config directories for the >> livecd ~/home to avoid the very first-start up time hit/config >> questions for the livecds >> > > As stated elsewhere, having all languages as a goal and having OO.org > as a goal are in direct conflict. oo.org+translations is over 700 megs > itself. > > for x86_64 we already use a dvd ... so why not add OO ? From davidz at redhat.com Thu Aug 2 11:51:37 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 02 Aug 2007 07:51:37 -0400 Subject: f8 desktop livecd In-Reply-To: <46B1C29B.9010109@gmail.com> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <46B1C29B.9010109@gmail.com> Message-ID: <1186055497.28137.13.camel@oneill.fubar.dk> On Thu, 2007-08-02 at 13:40 +0200, dragoran wrote: > for x86_64 we already use a dvd ... so why not add OO ? It's been a goal, earlier, to produce a distribution that fits on a CD for all the usual reasons: DVD media is more expensive, not everyone has DVD burners, some people don't even have DVD readers. Btw, some of us consider the goal of having multilib on the x86_64 desktop live cd wrong. I'm sure it makes a lot of sense for general Fedora users (especially those using an enterprise rebuild, *cough*, RHEL) but am not so sure that the segment we're trying to target really cares. And if they do care, our package management tools should be able to pull in the 32-bit requisite packages anyway (and I think the tools support this already). The latter is just one example of where we perhaps have to depart from traditional thinking. Historically it has caused a lot of friction and flame wars mainly because we've tried to please everyone with a single distribution called Fedora. By having a much tighter focus we need to revisit some our goals. This includes goals like "is it important it fits on CD media", "should we include all locales or have regional variants", "do we support multi-lib out of the box". I don't know what the answer is to any of these. At least it's worth thinking about. David From drago01 at gmail.com Thu Aug 2 12:13:16 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 02 Aug 2007 14:13:16 +0200 Subject: f8 desktop livecd In-Reply-To: <1186055497.28137.13.camel@oneill.fubar.dk> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <46B1C29B.9010109@gmail.com> <1186055497.28137.13.camel@oneill.fubar.dk> Message-ID: <46B1CA5C.20502@gmail.com> David Zeuthen wrote: > On Thu, 2007-08-02 at 13:40 +0200, dragoran wrote: > >> for x86_64 we already use a dvd ... so why not add OO ? >> > > It's been a goal, earlier, to produce a distribution that fits on a CD > for all the usual reasons: DVD media is more expensive, not everyone has > DVD burners, some people don't even have DVD readers. > > I doubt you will find a many *x86_64* boxes without dvd readers (or even burners). > Btw, some of us consider the goal of having multilib on the x86_64 > desktop live cd wrong. I disagre here people want third party apps to run out of the box and some of them are not shipped as x86_64 versions the best examples are flash and closed sources games like quake4. > I'm sure it makes a lot of sense for general > Fedora users (especially those using an enterprise rebuild, *cough*, > RHEL) but am not so sure that the segment we're trying to target really > cares. And if they do care, our package management tools should be able > to pull in the 32-bit requisite packages anyway (and I think the tools > support this already). > > if its about installing packages its true and they indeed gets pulled in. but still basic multilib support is needed for cases like I mentioned above. > [..] I don't know what the answer is to any of these. At > least it's worth thinking about. > > +1 From caolanm at redhat.com Thu Aug 2 12:33:28 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 02 Aug 2007 13:33:28 +0100 Subject: f8 desktop livecd In-Reply-To: <20070802073453.793671ad@ender> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> Message-ID: <1186058008.3239.70.camel@Nom> On Thu, 2007-08-02 at 07:34 -0400, Jesse Keating wrote: > On Thu, 02 Aug 2007 08:38:45 +0100 > Caolan McNamara wrote: > > > Just looked at the ubuntu livecd recently, has OOo on it and the gimp, > > the ubuntu gimp doesn't ask anything during first install. So it might > > be neat for the livecd/personal cd to include > > pre-canned .gimp-2.2/.openoffice.org2 config directories for the > > livecd ~/home to avoid the very first-start up time hit/config > > questions for the livecds > > As stated elsewhere, having all languages as a goal and having OO.org > as a goal are in direct conflict. oo.org+translations is over 700 megs > itself. Seems unfortunate that we can't use the livecd for e.g. emergency use for playing impress presentations because the total size for its translations would be too large. Blocking on "all OOo translations won't fit, so we must only pick apps whose complete translations fit" seems a little like cheating though. i.e. Abiword seems to have its help translated to just English, French and German, while Gnumeric seems to have just English(?) help and approx 15+ less translations than OOo. Sure, if the non-translated bits are fundamentally overscale to fit on cd vs the other options, or its too slow to run from CD, or we hate it too much to want it, then that's fine. But if the reason boiled down to solely having all languages supported on the cd as a goal and apps are then picked that have less translation coverage due to space reasons then that strikes me as a bit of a fudge. C. From jkeating at redhat.com Thu Aug 2 13:36:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 2 Aug 2007 09:36:34 -0400 Subject: f8 desktop livecd In-Reply-To: <1186058008.3239.70.camel@Nom> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> Message-ID: <20070802093634.785c9f0d@localhost.localdomain> On Thu, 02 Aug 2007 13:33:28 +0100 Caolan McNamara wrote: > Sure, if the non-translated bits are fundamentally overscale to fit on > cd vs the other options, or its too slow to run from CD, or we hate it > too much to want it, then that's fine. But if the reason boiled down > to solely having all languages supported on the cd as a goal and apps > are then picked that have less translation coverage due to space > reasons then that strikes me as a bit of a fudge. I don't disagree. However it's a lot easier to say "we don't support your language because there was no translation for it upstream" than to say "we don't support your language because we didn't think it was important enough to include on the media. Sorry.". Still, some thought could be put around having regional editions of the live image that include a set of the languages for that region or some other ideas such as that. It just takes somebody playing around with it (: The good news is that the tools are relatively easy so that those playing at home can try things out instead of waiting for something to fall out of the Red Hat black box. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Thu Aug 2 13:45:31 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 02 Aug 2007 09:45:31 -0400 Subject: f8 desktop livecd In-Reply-To: <20070802093634.785c9f0d@localhost.localdomain> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> Message-ID: <1186062331.998.122.camel@cutter> On Thu, 2007-08-02 at 09:36 -0400, Jesse Keating wrote: > On Thu, 02 Aug 2007 13:33:28 +0100 > Caolan McNamara wrote: > > > Sure, if the non-translated bits are fundamentally overscale to fit on > > cd vs the other options, or its too slow to run from CD, or we hate it > > too much to want it, then that's fine. But if the reason boiled down > > to solely having all languages supported on the cd as a goal and apps > > are then picked that have less translation coverage due to space > > reasons then that strikes me as a bit of a fudge. > > I don't disagree. However it's a lot easier to say "we don't support > your language because there was no translation for it upstream" than to > say "we don't support your language because we didn't think it was > important enough to include on the media. Sorry.". > > Still, some thought could be put around having regional editions of the > live image that include a set of the languages for that region or some > other ideas such as that. It just takes somebody playing around with > it (: The good news is that the tools are relatively easy so that > those playing at home can try things out instead of waiting for > something to fall out of the Red Hat black box. > +1. A while back gnome made a gnome preview live cd. It was a version of the gnome using an ubuntu livecd. They did one for the various languages that wanted them - hitting most of the 'major' languages and then doing others on request. -sv From caolanm at redhat.com Thu Aug 2 13:58:34 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 02 Aug 2007 14:58:34 +0100 Subject: f8 desktop livecd In-Reply-To: <20070802093634.785c9f0d@localhost.localdomain> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> Message-ID: <1186063114.3239.88.camel@Nom> On Thu, 2007-08-02 at 09:36 -0400, Jesse Keating wrote: > On Thu, 02 Aug 2007 13:33:28 +0100 > Caolan McNamara wrote: > Still, some thought could be put around having regional editions of the > live image that include a set of the languages for that region or some > other ideas such as that. Yeah, that's where I was going, a single global cd is tricky in the long run even excluding OOo. We currently get away with it because we're not generally massively translated, except for poor OOo, and even there I'm already skipping building about 18 languages which don't have any have existing support in the rest of our desktop e.g having no available free fonts to display the language or it would be the only translated application into that language. I'd well imagine that if the existing set of software gets translated to the same extent that we'd have trouble fitting in onto a cd :-( Most companies have the luxury of a formal or informal big 7 or big 12 language policy, and e.g. Dzongkha and Irish can forget about being supported. I guess the ideal solution for something like fedora would be a set of regional cds, though I'm not enthusiastic about actually contributing constructively and doing the work :-) C. From jspaleta at gmail.com Thu Aug 2 16:04:04 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Aug 2007 08:04:04 -0800 Subject: f8 desktop livecd In-Reply-To: <1186062331.998.122.camel@cutter> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186062331.998.122.camel@cutter> Message-ID: <604aa7910708020904s77f7cd57tffdda71a1a342416@mail.gmail.com> On 8/2/07, seth vidal wrote: > +1. > A while back gnome made a gnome preview live cd. It was a version of the > gnome using an ubuntu livecd. They did one for the various languages > that wanted them - hitting most of the 'major' languages and then doing > others on request. on request...... sounds like the perfect job for wevisor, and its template archive. http://publictest1.fedora.redhat.com/wevisor/ -jef"did i mention that wevisor looks like its going to kick ass"spaleta From jspaleta at gmail.com Thu Aug 2 16:12:27 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Aug 2007 08:12:27 -0800 Subject: f8 desktop livecd In-Reply-To: <1186063114.3239.88.camel@Nom> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> Message-ID: <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> On 8/2/07, Caolan McNamara wrote: > Most companies have the luxury of a formal or informal big 7 or big 12 > language policy, and e.g. Dzongkha and Irish can forget about being > supported. I guess the ideal solution for something like fedora would be > a set of regional cds, though I'm not enthusiastic about actually > contributing constructively and doing the work :-) Are all the translations broken out into subpackages in sane way across the distro? Or is there re-packaging work that needs to be done to make it possible to respin regionally? Are there any other major roadblocks to someone making a regional cd right now using something like revisor? I think regional cds are the way to go, but I'm not sure its appropriate to change policy in terms of how we handle translations for the F8 timescale. I think we could probably decide...soon-ish..that we want to go regional for F9, and start prioritizing the work to get from here to there. That would also give "us" some time to have solid discussions with the non-EN/US speakers about jumping on board to help create the re-spins. -jef From notting at redhat.com Thu Aug 2 16:14:56 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Aug 2007 12:14:56 -0400 Subject: f8 desktop livecd In-Reply-To: <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> References: <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> Message-ID: <20070802161456.GA15802@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > On 8/2/07, Caolan McNamara wrote: > > Most companies have the luxury of a formal or informal big 7 or big 12 > > language policy, and e.g. Dzongkha and Irish can forget about being > > supported. I guess the ideal solution for something like fedora would be > > a set of regional cds, though I'm not enthusiastic about actually > > contributing constructively and doing the work :-) > > Are all the translations broken out into subpackages in sane way > across the distro? For OO.o and KDE, they are split. For other packages, they are not. Whether to split or not is a long, drawn-out conversation. (Basically, you make building liveCDs easier at the cost of making all languages Just Work much harder.) Bill From drago01 at gmail.com Thu Aug 2 16:20:13 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 2 Aug 2007 18:20:13 +0200 Subject: f8 desktop livecd In-Reply-To: <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> Message-ID: On 8/2/07, Jeff Spaleta wrote: > > [...] That would also give > "us" some time to have solid discussions with the non-EN/US speakers > about jumping on board to help create the re-spins. creating spins for _each_ language is overkill we can have more than one on a cd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Thu Aug 2 16:48:31 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Aug 2007 08:48:31 -0800 Subject: f8 desktop livecd In-Reply-To: References: <1185552270.3323.58.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> Message-ID: <604aa7910708020948u427924f4p7cb291a49e07c411@mail.gmail.com> On 8/2/07, dragoran wrote: > creating spins for _each_ language is overkill we can have more than one on > a cd. Yes of course... regions. -jef"dreams of a day when Fedora can have a livecd for all indigenous North American Arctic languages. I really need to talk to the language center here on campus."spaleta From jspaleta at gmail.com Thu Aug 2 16:59:07 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Aug 2007 08:59:07 -0800 Subject: f8 desktop livecd In-Reply-To: <20070802161456.GA15802@nostromo.devel.redhat.com> References: <1185991239.2822.45.camel@oneill.fubar.dk> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> <20070802161456.GA15802@nostromo.devel.redhat.com> Message-ID: <604aa7910708020959l537c3dd1s5cfd6d029d01d2c@mail.gmail.com> On 8/2/07, Bill Nottingham wrote: > For OO.o and KDE, they are split. For other packages, they are not. > Whether to split or not is a long, drawn-out conversation. (Basically, > you make building liveCDs easier at the cost of making all languages > Just Work much harder.) Is there a fundamental technology shift that we have to swallow? Or is it more a death by a thousand cuts if we go in and start package surgery? For crap that has a lot of translation coverage, then it becomes more important an issue. I'll rephrase the question, if we decided that a single package needed to have its translations split off.. is there a known set of things that need to be adjusted? And do we have an idea what the next largest package is that would add additional flexibility for regional cd creation? it's never easy...but is it too hard to do by F9? I think if we are serious about focusing, then livecds are the best vechicle we have to explore focused space, in a way that gives external community a chance to help define cool foci. And if we can get to the point where regional cds are possible, that will significantly add in our flexibility moving forward. -jef"Penalizing openoffice because it does have significant translation support is a little ass-backwards."spaleta From notting at redhat.com Thu Aug 2 17:03:02 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Aug 2007 13:03:02 -0400 Subject: f8 desktop livecd In-Reply-To: <604aa7910708020959l537c3dd1s5cfd6d029d01d2c@mail.gmail.com> References: <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> <20070802161456.GA15802@nostromo.devel.redhat.com> <604aa7910708020959l537c3dd1s5cfd6d029d01d2c@mail.gmail.com> Message-ID: <20070802170302.GB17571@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > On 8/2/07, Bill Nottingham wrote: > > For OO.o and KDE, they are split. For other packages, they are not. > > Whether to split or not is a long, drawn-out conversation. (Basically, > > you make building liveCDs easier at the cost of making all languages > > Just Work much harder.) > > Is there a fundamental technology shift that we have to swallow? Or is > it more a death by a thousand cuts if we go in and start package > surgery? The issue is that as soon as you split the package, you end up having to track both all the splits of that package and the union of all languages that have translations manually in comps for all releases where you may have that package. Moreover, users cannot easily add these languages later to their system. If you do not split, all these problems go away. Bill From jkeating at redhat.com Thu Aug 2 17:05:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 2 Aug 2007 13:05:51 -0400 Subject: f8 desktop livecd In-Reply-To: <604aa7910708020959l537c3dd1s5cfd6d029d01d2c@mail.gmail.com> References: <1185991239.2822.45.camel@oneill.fubar.dk> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> <20070802161456.GA15802@nostromo.devel.redhat.com> <604aa7910708020959l537c3dd1s5cfd6d029d01d2c@mail.gmail.com> Message-ID: <20070802130551.3e8f373f@localhost.localdomain> On Thu, 2 Aug 2007 08:59:07 -0800 "Jeff Spaleta" wrote: > I'll rephrase the question, if we > decided that a single package needed to have its translations split > off.. is there a known set of things that need to be adjusted? Lots and lots more conditionals in comps, and making sure that everything that groks comps really does conditionals well, and that is a hard path. (conditionals are difficult to get right) -- 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 jspaleta at gmail.com Thu Aug 2 17:10:48 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Aug 2007 09:10:48 -0800 Subject: f8 desktop livecd In-Reply-To: <20070802170302.GB17571@nostromo.devel.redhat.com> References: <20070801144635.5c2c361c@localhost.localdomain> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> <20070802161456.GA15802@nostromo.devel.redhat.com> <604aa7910708020959l537c3dd1s5cfd6d029d01d2c@mail.gmail.com> <20070802170302.GB17571@nostromo.devel.redhat.com> Message-ID: <604aa7910708021010kd3d2396v928bbdae5f831ca0@mail.gmail.com> On 8/2/07, Bill Nottingham wrote: > If you do not split, all these problems go away. so fundamental technology issue. We can't duck this forever. I if the new kick ass localization project does their job.. you'll have to deal with this sooner than later when the perfect future of all applications with full translation support walks up and steals your lunch money. If we had full translation support for everything in the repository, how functional would a desktop oriented livecd actually be? -jef From mclasen at redhat.com Thu Aug 2 17:14:01 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 02 Aug 2007 13:14:01 -0400 Subject: f8 desktop livecd In-Reply-To: <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> Message-ID: <1186074841.3541.0.camel@dhcp83-186.boston.redhat.com> On Thu, 2007-08-02 at 08:12 -0800, Jeff Spaleta wrote: > On 8/2/07, Caolan McNamara wrote: > > Most companies have the luxury of a formal or informal big 7 or big 12 > > language policy, and e.g. Dzongkha and Irish can forget about being > > supported. I guess the ideal solution for something like fedora would be > > a set of regional cds, though I'm not enthusiastic about actually > > contributing constructively and doing the work :-) > > Are all the translations broken out into subpackages in sane way > across the distro? Or is there re-packaging work that needs to be done > to make it possible to respin regionally? > Are there any other major roadblocks to someone making a regional cd > right now using something like revisor? > > I think regional cds are the way to go, but I'm not sure its > appropriate to change policy in terms of how we handle translations > for the F8 timescale. I think we could probably > decide...soon-ish..that we want to go regional for F9, and start > prioritizing the work to get from here to there. That would also give > "us" some time to have solid discussions with the non-EN/US speakers > about jumping on board to help create the re-spins. Wouldn't you use the rpm mechanism to install a subset of languages for that ? From notting at redhat.com Thu Aug 2 17:17:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Aug 2007 13:17:10 -0400 Subject: f8 desktop livecd In-Reply-To: <1186074841.3541.0.camel@dhcp83-186.boston.redhat.com> References: <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> <1186074841.3541.0.camel@dhcp83-186.boston.redhat.com> Message-ID: <20070802171710.GC17571@nostromo.devel.redhat.com> Matthias Clasen (mclasen at redhat.com) said: > Wouldn't you use the rpm mechanism to install a subset of languages for > that ? If we set the lang tsflags in the yum process creating the FS for the livecd... this could theoretically work. Without splitting the packages. Which is good. Bill From jspaleta at gmail.com Thu Aug 2 17:34:05 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Aug 2007 09:34:05 -0800 Subject: f8 desktop livecd In-Reply-To: <20070802171710.GC17571@nostromo.devel.redhat.com> References: <1185993793.3123.31.camel@neutron.verbum.private> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> <1186074841.3541.0.camel@dhcp83-186.boston.redhat.com> <20070802171710.GC17571@nostromo.devel.redhat.com> Message-ID: <604aa7910708021034p37159c02j8db2299fa4b57e92@mail.gmail.com> On 8/2/07, Bill Nottingham wrote: > If we set the lang tsflags in the yum process creating the FS for the > livecd... this could theoretically work. Without splitting the packages. > Which is good. So doom avoided... theoretically? -jef From davidz at redhat.com Thu Aug 2 17:46:14 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 02 Aug 2007 13:46:14 -0400 Subject: f8 desktop livecd In-Reply-To: <604aa7910708021034p37159c02j8db2299fa4b57e92@mail.gmail.com> References: <1185993793.3123.31.camel@neutron.verbum.private> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> <1186074841.3541.0.camel@dhcp83-186.boston.redhat.com> <20070802171710.GC17571@nostromo.devel.redhat.com> <604aa7910708021034p37159c02j8db2299fa4b57e92@mail.gmail.com> Message-ID: <1186076774.3024.22.camel@oneill.fubar.dk> On Thu, 2007-08-02 at 09:34 -0800, Jeff Spaleta wrote: > On 8/2/07, Bill Nottingham wrote: > > If we set the lang tsflags in the yum process creating the FS for the > > livecd... this could theoretically work. Without splitting the packages. > > Which is good. > > So doom avoided... theoretically? However, this way of doing things won't allow you to extra language support later. Unless someone builds technology to do this. It may not be a big problem. David From mclasen at redhat.com Thu Aug 2 17:47:36 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 02 Aug 2007 13:47:36 -0400 Subject: f8 desktop livecd In-Reply-To: <1186076774.3024.22.camel@oneill.fubar.dk> References: <1185993793.3123.31.camel@neutron.verbum.private> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> <1186074841.3541.0.camel@dhcp83-186.boston.redhat.com> <20070802171710.GC17571@nostromo.devel.redhat.com> <604aa7910708021034p37159c02j8db2299fa4b57e92@mail.gmail.com> <1186076774.3024.22.camel@oneill.fubar.dk> Message-ID: <1186076856.3541.4.camel@dhcp83-186.boston.redhat.com> On Thu, 2007-08-02 at 13:46 -0400, David Zeuthen wrote: > On Thu, 2007-08-02 at 09:34 -0800, Jeff Spaleta wrote: > > On 8/2/07, Bill Nottingham wrote: > > > If we set the lang tsflags in the yum process creating the FS for the > > > livecd... this could theoretically work. Without splitting the packages. > > > Which is good. > > > > So doom avoided... theoretically? > > However, this way of doing things won't allow you to extra language > support later. Unless someone builds technology to do this. It may not > be a big problem. > Sounds like a solvable problem. rpm would have to keep track of which packages have been installed with a restricted set of languages, and then reinstall them if the set of installed languages changes later. Or something like that. From walters at redhat.com Thu Aug 2 18:05:15 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 02 Aug 2007 14:05:15 -0400 Subject: livecd hacking In-Reply-To: <20070802121453.1f16ad52@localhost.localdomain> References: <1185920349.12650.4.camel@neutron.verbum.private> <20070802121453.1f16ad52@localhost.localdomain> Message-ID: <1186077915.3435.3.camel@neutron.verbum.private> On Thu, 2007-08-02 at 12:14 +0200, Sebastian Vahl wrote: > livecd-fedora-kde.ks is working but installs too much more packages > than the old config (and also some unwanted, eg. gnome-games). Awesome, thanks for taking a look at this. > This is > related to livecd-desktop-minimal.ks which includes more groups than > the kde config. If the kde livecd should also use this config some > groups should be removed. The size with livecd-desktop-minimal.ks is > here (i386) 770 megs to 687 megs with the normal config. You should feel free to kill off stuff in -desktop-minimal; the intent is it just launches TWM. Are you going to have a chance to do any work on the KDE livecd soon? Ideally this work would all go in the livecd repo, I'd just feel uncomfortable committing such a big patch without review from Jeremy. From walters at redhat.com Thu Aug 2 18:07:03 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 02 Aug 2007 14:07:03 -0400 Subject: f8 desktop livecd In-Reply-To: <46B19437.7040204@gmail.com> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <46B19437.7040204@gmail.com> Message-ID: <1186078023.3435.5.camel@neutron.verbum.private> On Thu, 2007-08-02 at 10:22 +0200, dragoran wrote: > Colin Walters wrote: > > > Ok. Here's my suggestion. We call this "*Fedora Personal Laptop*". Skip > > the word "Desktop" because it means too many different things. > > > > > This is a awfull name. If you call it "Laptop" only people who use/have > laptops will download and use it. But it should be targeted at _desktop_ > users .. so whats wrong with the name desktop? > You can do atleast s/Laptop/Desktop/ I don't actually care a lot about the name - if consensus seems to be in favor of Desktop that's fine. From jspaleta at gmail.com Thu Aug 2 18:16:41 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Aug 2007 10:16:41 -0800 Subject: f8 desktop livecd In-Reply-To: <1186078023.3435.5.camel@neutron.verbum.private> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <46B19437.7040204@gmail.com> <1186078023.3435.5.camel@neutron.verbum.private> Message-ID: <604aa7910708021116t34013915h28c6f34de96f566a@mail.gmail.com> On 8/2/07, Colin Walters wrote: > I don't actually care a lot about the name - if consensus seems to be in > favor of Desktop that's fine. Perhaps it would be better to avoid the laptop/desktop/server language entirely. Fedora Workspace CD? "Get working now" Fedora Now CD? Fedora On-the-Go CD? "Always on the move with Fedora" Fedora Essentials CD? "Essentials for everyday computing...anywhere" -jef From ml at deadbabylon.de Fri Aug 3 10:32:29 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Fri, 3 Aug 2007 12:32:29 +0200 Subject: livecd hacking In-Reply-To: <1186077915.3435.3.camel@neutron.verbum.private> References: <1185920349.12650.4.camel@neutron.verbum.private> <20070802121453.1f16ad52@localhost.localdomain> <1186077915.3435.3.camel@neutron.verbum.private> Message-ID: <200708031232.42374.ml@deadbabylon.de> Am Do 2.August 2007 schrieb Colin Walters: > On Thu, 2007-08-02 at 12:14 +0200, Sebastian Vahl wrote: > > livecd-fedora-kde.ks is working but installs too much more packages > > than the old config (and also some unwanted, eg. gnome-games). > > Awesome, thanks for taking a look at this. > > > This is > > related to livecd-desktop-minimal.ks which includes more groups than > > the kde config. If the kde livecd should also use this config some > > groups should be removed. The size with livecd-desktop-minimal.ks is > > here (i386) 770 megs to 687 megs with the normal config. > > You should feel free to kill off stuff in -desktop-minimal; the intent > is it just launches TWM. Are you going to have a chance to do any work > on the KDE livecd soon? I will not be at home over the weekend. But I try to test some changes on monday. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ml at deadbabylon.de Tue Aug 7 16:47:31 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 7 Aug 2007 18:47:31 +0200 Subject: livecd hacking In-Reply-To: <200708031232.42374.ml@deadbabylon.de> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186077915.3435.3.camel@neutron.verbum.private> <200708031232.42374.ml@deadbabylon.de> Message-ID: <200708071847.36297.ml@deadbabylon.de> Am Fr 3.August 2007 schrieb Sebastian Vahl: > Am Do 2.August 2007 schrieb Colin Walters: > > On Thu, 2007-08-02 at 12:14 +0200, Sebastian Vahl wrote: > > > livecd-fedora-kde.ks is working but installs too much more packages > > > than the old config (and also some unwanted, eg. gnome-games). > > > > Awesome, thanks for taking a look at this. > > > > > This is > > > related to livecd-desktop-minimal.ks which includes more groups than > > > the kde config. If the kde livecd should also use this config some > > > groups should be removed. The size with livecd-desktop-minimal.ks is > > > here (i386) 770 megs to 687 megs with the normal config. > > > > You should feel free to kill off stuff in -desktop-minimal; the intent > > is it just launches TWM. Are you going to have a chance to do any work > > on the KDE livecd soon? > > I will not be at home over the weekend. But I try to test some changes on > monday. > > Sebastian Well, I didn't had much time. But these config is more closer to the normal one. I removed only @games from livecd-desktop-minimal.ks and removed the further not wanted packages in livecd-fedora-kde.ks. But the list is not complete yet. Sebastian -------------- next part -------------- %include livecd-desktop-minimal.ks %packages @kde-desktop kdegames beryl-kde k3b koffice-kword koffice-kspread koffice-kpresenter koffice-filters twinkle # if it is enough space include koffice-krita (~40 megs) koffice-krita #some changes that we don't want... -scribus -kdeaddons -kdemultimedia-extras -kdeartwork-extras -kmymoney2 -basket # some other extra packages gnupg xine-lib-extras # remove some packages from dekstop-minimal.ks -scim* -system-config-printer* -gdm -authconfig-gtk -m17n* -xorg-x11-fonts-* -xorg-x11-twm -PolicyKit-gnome -libbeagle -yelp -firefox -desktop-backgrounds-basic -gnome-doc-utils-stylesheets # ignore comps.xml and make sure these packages are included knetworkmanager kpowersave redhat-artwork-kde rhgb %post # create /etc/sysconfig/desktop (needed for installation) cat > /etc/sysconfig/desktop <> /etc/rc.d/init.d/fedora-live-kde << EOF if [ -e /usr/share/icons/hicolor/96x96/apps/fedora-logo-icon.png ] ; then # use image also for kdm mkdir -p /usr/share/apps/kdm/faces cp /usr/share/icons/hicolor/96x96/apps/fedora-logo-icon.png /usr/share/apps/kdm/faces/fedora.face.icon fi # make fedora user use KDE echo "startkde" > /home/fedora/.xsession chmod a+x /home/fedora/.xsession chown fedora:fedora /home/fedora/.xsession # set up autologin for user fedora sed -i 's/#AutoLoginEnable=true/AutoLoginEnable=true/' /etc/kde/kdm/kdmrc sed -i 's/#AutoLoginUser=fred/AutoLoginUser=fedora/' /etc/kde/kdm/kdmrc # set up user fedora as default user and preselected user sed -i 's/#PreselectUser=Default/PreselectUser=Default/' /etc/kde/kdm/kdmrc sed -i 's/#DefaultUser=johndoe/DefaultUser=fedora/' /etc/kde/kdm/kdmrc # disable screensaver sed -i 's/Enabled=true/Enabled=false/' /usr/share/kde-settings/kde-profile/default/share/config/kdesktoprc # adding some autostarted applications cp /usr/share/applications/fedora-knetworkmanager.desktop /usr/share/autostart/ # workaround to put liveinst on desktop and in menu sed -i 's/NoDisplay=true/NoDisplay=false/' /usr/share/applications/liveinst.desktop EOF -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Tue Aug 7 18:03:04 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 14:03:04 -0400 Subject: f8 desktop livecd In-Reply-To: <1185927215.14236.28.camel@neutron.verbum.private> References: <1185552270.3323.58.camel@neutron.verbum.private> <46AB2386.4060606@fedoraproject.org> <1185759043.3422.13.camel@neutron.verbum.private> <46AD9EBD.3030804@fedoraproject.org> <1185927215.14236.28.camel@neutron.verbum.private> Message-ID: <1186509784.6256.51.camel@localhost.localdomain> (Lalala... back from vacation, lots of mail.) On Tue, 2007-07-31 at 20:13 -0400, Colin Walters wrote: > On Mon, 2007-07-30 at 13:48 +0530, Rahul Sundaram wrote: > > Colin Walters wrote: > > > Right, though ideally this isn't a big formal project, just a place > > > where we can tweak some defaults or the like. I think a lot depends on > > > how much time is spent on it, but agreed that at this point it seems > > > clear that we need to differentiate things better on the website at a > > > minimum. Not sure what that text should say yet though... > > > > When we say the Live images are desktop focused, what do we mean by > > that? Configuration changes like network manager by default, subset of > > Fedora that is good for desktop usage or something else? > > Ok. In this discussion, one thing I'd like to keep in mind is that the > technical fact that it's a "Live CD" or "Live Media" is not the > interesting part. What is interesting is that it makes some attempt at > choosing a target audience and defaults+tweaks for that target[1]. Exactly. And it's even less interesting to focus on it being a live CD as we're working towards having common formats being used to describe all of live images, a "tree spin", and even "installing from the everything tree". That said, I think we're likely to want to target a live CD as the primary deployment/distribution vehicle. Jeremy From katzj at redhat.com Tue Aug 7 18:05:15 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 14:05:15 -0400 Subject: f8 desktop livecd In-Reply-To: <1186055497.28137.13.camel@oneill.fubar.dk> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <46B1C29B.9010109@gmail.com> <1186055497.28137.13.camel@oneill.fubar.dk> Message-ID: <1186509915.6256.55.camel@localhost.localdomain> On Thu, 2007-08-02 at 07:51 -0400, David Zeuthen wrote: > By having a much tighter focus we need to revisit some our goals. Just for historical background of a few of these (not saying we shouldn't revisit them, but so everyone starts on the same page so to speak) > This includes goals like "is it important it fits on CD media", Feedback from non-US/non-European based locales is that CD media is still very important. The fact that the "Fedora spin" is DVD only gets a reasonable amount of flak, but it tends to be deflected with "go use the live CD" :) > "should we include all locales or have regional variants", Regional variants implies a need for more storage and more testing time. That's the historical thinking anyway > "do we support multi-lib out of the box". The processor vendors are *huge* fans of this and users _who take advantage of it_ are also. The argument is that without the 32bit-ness available and there with no intervention needed, you might as well switch to a different arch altogether. Jeremy From katzj at redhat.com Tue Aug 7 18:05:27 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 14:05:27 -0400 Subject: f8 desktop livecd In-Reply-To: <20070802161456.GA15802@nostromo.devel.redhat.com> References: <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> <20070802161456.GA15802@nostromo.devel.redhat.com> Message-ID: <1186509927.6256.56.camel@localhost.localdomain> On Thu, 2007-08-02 at 12:14 -0400, Bill Nottingham wrote: > Jeff Spaleta (jspaleta at gmail.com) said: > > On 8/2/07, Caolan McNamara wrote: > > > Most companies have the luxury of a formal or informal big 7 or big 12 > > > language policy, and e.g. Dzongkha and Irish can forget about being > > > supported. I guess the ideal solution for something like fedora would be > > > a set of regional cds, though I'm not enthusiastic about actually > > > contributing constructively and doing the work :-) > > > > Are all the translations broken out into subpackages in sane way > > across the distro? > > For OO.o and KDE, they are split. For other packages, they are not. > Whether to split or not is a long, drawn-out conversation. (Basically, > you make building liveCDs easier at the cost of making all languages > Just Work much harder.) %{lang} tagging is simple enough to take advantage of with the live images if we want. Just needs a) way to specify it (return of langsupport!) and b) then actually setting the rpm macro. You're kind of screwed if you ever want to add more translations, but that is a tradeoff that could be made. But the discussion about that is going on in a different thread too :-) Jeremy From katzj at redhat.com Tue Aug 7 18:05:42 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 14:05:42 -0400 Subject: f8 desktop livecd In-Reply-To: <604aa7910708021116t34013915h28c6f34de96f566a@mail.gmail.com> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <46B19437.7040204@gmail.com> <1186078023.3435.5.camel@neutron.verbum.private> <604aa7910708021116t34013915h28c6f34de96f566a@mail.gmail.com> Message-ID: <1186509942.6256.59.camel@localhost.localdomain> On Thu, 2007-08-02 at 10:16 -0800, Jeff Spaleta wrote: > On 8/2/07, Colin Walters wrote: > > I don't actually care a lot about the name - if consensus seems to be in > > favor of Desktop that's fine. > > Perhaps it would be better to avoid the laptop/desktop/server language entirely. I more and more think there's a lot of validity to this line of thinking... > Fedora Workspace CD? "Get working now" > Fedora Now CD? > Fedora On-the-Go CD? "Always on the move with Fedora" > Fedora Essentials CD? "Essentials for everyday computing...anywhere" I kind of like the last one. But what the hell do I know? :-) Jeremy From katzj at redhat.com Tue Aug 7 18:07:38 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 14:07:38 -0400 Subject: f8 desktop livecd In-Reply-To: <1185991239.2822.45.camel@oneill.fubar.dk> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> Message-ID: <1186510058.6256.61.camel@localhost.localdomain> On Wed, 2007-08-01 at 14:00 -0400, David Zeuthen wrote: > I mean, just take a look at the delta between the F6 and F7 live CD: > Notable differences [some snipping] > - FC6 live CD included more, uh, apps with a desktop focus that > were not in the F7 live CD (due to lack of disc space) > - Beagle, F-Spot, Inkscape, VPN tools (vpnc, openvpn) FWIW, the vast majority of your list here wasn't due to space. Beagle was because we disabled beagle _in general_ for the desktop[1]. f-spot just isn't the default photo app -- if it should be, let's swap it and gthumb in comps. VPN tools was just an omission as I thought I had fixed it but apparently I suck ;-) Inkscape is really the only one that was driven off purely from a space perspective. [snip] > So we tell everyone to use "Fedora Desktop" instead. What's missing here > is the upgrade story and our current story is "use anaconda to upgrade" > which I think is pretty lame. We're asking people to go to d.fp.org > (which already sucks) and make them download an ISO. A lot of the work for improving this is based on one of the fedora-devel threads is underway. Basically, an app you can run to download the packages and set everything up to reboot you into the installer to do the actual upgrade. Need to do a little bit more experimentation to prove things out, but it's looking somewhat promising. (Note to self: need to do the feature write-up for it). Once we've had it working for a release or so, wiring in a "hey, there's a new version available" thing pop up is definitely doable. [more snipping] > I have a lot of thoughts about technical details and what set of > packages should (and shouldn't) go on the Fedora Desktop Live CD. For > example, I mean, a desktop system clearly don't need junk like > system-config-keyboard or system-config-language since we don't care > about the console. Actually, for these, the bigger problem is that some of our tools (like the installer) depends on them being there as we decided to actually make things modular and reuse components. Damned when we do, damned when we don't. Can probably do something to make those requirements fall back to just "figuring things out" when they're not there and not doing the questions. At the same time, all of system-config-* is < 15 megs. And once you take out the stuff not on the livecd (bind, network can go once NetworkManager can configure dial-up, kickstart, soundcard, ..) we're talking about 3 megs. So maybe not a big win although if someone wants to work on the anaconda patch, I'd be glad to review it and get it committed. Jeremy [1] Note, beagle has other annoying characteristics when being used with the liveCD in that it starts indexing the world chewing up memory for its indices which then have to be redone all the time. Also, lots of CD seeking... From katzj at redhat.com Tue Aug 7 18:28:22 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 14:28:22 -0400 Subject: livecd hacking In-Reply-To: <1185920349.12650.4.camel@neutron.verbum.private> References: <1185920349.12650.4.camel@neutron.verbum.private> Message-ID: <1186511302.6256.72.camel@localhost.localdomain> On Tue, 2007-07-31 at 18:19 -0400, Colin Walters wrote: > I've done some work on the Live CD kickstart images, available here: > http://submind.verbum.org/~walters/livecd.git/ > > (Until Jeremy returns from vacation and can review patches to be put in > the main livecd git repository) I'm baaaccckkkkk :-) > The most important change so far is to create > "livecd-desktop-minimal.ks" which is then used as a basis for: At a glance, this part looks reasonable. Need to fix up %include so that it doesn't depend on the working directory. But that looks pretty trivial -- we just need to subclass KickstartParser and override readKickstart() with a method that finds the file. Otherwise, people will hit what svahl did. > I also added a number of improvements to livecd-creator, the git log has > the gory details. Patches to the actual creator code to fedora-livecd-list if you don't mind so that I can review them there. I don't necessarily disagree with them, but it becomes a bit easier to review them more as specific patches on the list. Jeremy From sundaram at fedoraproject.org Tue Aug 7 18:42:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 00:12:50 +0530 Subject: f8 desktop livecd In-Reply-To: <1186509915.6256.55.camel@localhost.localdomain> References: <1185552270.3323.58.camel@neutron.verbum.private> <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <46B1C29B.9010109@gmail.com> <1186055497.28137.13.camel@oneill.fubar.dk> <1186509915.6256.55.camel@localhost.localdomain> Message-ID: <46B8BD2A.1090000@fedoraproject.org> Jeremy Katz wrote: > Feedback from non-US/non-European based locales is that CD media is > still very important. The fact that the "Fedora spin" is DVD only gets > a reasonable amount of flak, but it tends to be deflected with "go use > the live CD" :) That doesn't always work. We have got several dozen people asking about this despite the presence of installable live images. 1) There are people who want access to a large number of packages but don't have a high bandwidth connection or DVD drive. Lack of full media support in yum and friends makes it hard too. Integrating Jidgo into the release process might be useful for them. Also Opyum. 2) On x86_64 you have to use special CD media or usually DVD but you don't get all the packages you could fill in a DVD. If you want to continue insisting on multi-lib by default then a better solution might be to cut down on the x86 image size so that the x86_64 image still fits on a CD. 3) We haven't yet worked out a good upgrade solution for those who have installed from a live image. If you get the anaconda based semi live upgrade solution before Fedora 8 release, we should be ok. Rahul From notting at redhat.com Tue Aug 7 18:51:56 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Aug 2007 14:51:56 -0400 Subject: f8 desktop livecd In-Reply-To: <46B8BD2A.1090000@fedoraproject.org> References: <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <46B1C29B.9010109@gmail.com> <1186055497.28137.13.camel@oneill.fubar.dk> <1186509915.6256.55.camel@localhost.localdomain> <46B8BD2A.1090000@fedoraproject.org> Message-ID: <20070807185156.GA14152@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > 2) On x86_64 you have to use special CD media or usually DVD but you don't > get all the packages you could fill in a DVD. If you want to continue > insisting on multi-lib by default then a better solution might be to cut > down on the x86 image size so that the x86_64 image still fits on a CD. I don't understand this... you have a DVD burner/reader but now *media* is a problem? Bill From sundaram at fedoraproject.org Tue Aug 7 19:05:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 00:35:40 +0530 Subject: f8 desktop livecd In-Reply-To: <20070807185156.GA14152@nostromo.devel.redhat.com> References: <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <46B1C29B.9010109@gmail.com> <1186055497.28137.13.camel@oneill.fubar.dk> <1186509915.6256.55.camel@localhost.localdomain> <46B8BD2A.1090000@fedoraproject.org> <20070807185156.GA14152@nostromo.devel.redhat.com> Message-ID: <46B8C284.3060604@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> 2) On x86_64 you have to use special CD media or usually DVD but you don't >> get all the packages you could fill in a DVD. If you want to continue >> insisting on multi-lib by default then a better solution might be to cut >> down on the x86 image size so that the x86_64 image still fits on a CD. > > I don't understand this... you have a DVD burner/reader but now *media* is a > problem? Wasn't talking about myself but there are a number of x86_64 systems (and want the x86_64 version of Fedora ) without a DVD drive out there. If they don't have a high bandwidth connection it is tricky for them to do a installation of Fedora 7. You could copy DVD drive to a separate partition and do a hard disk installation but I don't think that should be the only way. Rahul From sundaram at fedoraproject.org Tue Aug 7 19:08:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 00:38:48 +0530 Subject: f8 desktop livecd In-Reply-To: <46B8C284.3060604@fedoraproject.org> References: <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <46B1C29B.9010109@gmail.com> <1186055497.28137.13.camel@oneill.fubar.dk> <1186509915.6256.55.camel@localhost.localdomain> <46B8BD2A.1090000@fedoraproject.org> <20070807185156.GA14152@nostromo.devel.redhat.com> <46B8C284.3060604@fedoraproject.org> Message-ID: <46B8C340.3030907@fedoraproject.org> Rahul Sundaram wrote: You could copy DVD drive to a separate > partition and do a hard disk installation but I don't think that should > be the only way. Here, I meant copy the DVD image, not the drive obviously. Rahul From notting at redhat.com Tue Aug 7 19:15:12 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Aug 2007 15:15:12 -0400 Subject: f8 desktop livecd In-Reply-To: <46B8C284.3060604@fedoraproject.org> References: <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <46B1C29B.9010109@gmail.com> <1186055497.28137.13.camel@oneill.fubar.dk> <1186509915.6256.55.camel@localhost.localdomain> <46B8BD2A.1090000@fedoraproject.org> <20070807185156.GA14152@nostromo.devel.redhat.com> <46B8C284.3060604@fedoraproject.org> Message-ID: <20070807191512.GA14637@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > Wasn't talking about myself but there are a number of x86_64 systems (and > want the x86_64 version of Fedora ) without a DVD drive out there. Surely you mean 'without an optical drive'. Bill From sundaram at fedoraproject.org Tue Aug 7 19:22:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 00:52:37 +0530 Subject: f8 desktop livecd In-Reply-To: <20070807191512.GA14637@nostromo.devel.redhat.com> References: <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <46B1C29B.9010109@gmail.com> <1186055497.28137.13.camel@oneill.fubar.dk> <1186509915.6256.55.camel@localhost.localdomain> <46B8BD2A.1090000@fedoraproject.org> <20070807185156.GA14152@nostromo.devel.redhat.com> <46B8C284.3060604@fedoraproject.org> <20070807191512.GA14637@nostromo.devel.redhat.com> Message-ID: <46B8C67D.8080309@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> Wasn't talking about myself but there are a number of x86_64 systems (and >> want the x86_64 version of Fedora ) without a DVD drive out there. > > Surely you mean 'without an optical drive'. Are you referring to things like USB? Rahul From notting at redhat.com Tue Aug 7 19:33:53 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Aug 2007 15:33:53 -0400 Subject: f8 desktop livecd In-Reply-To: <46B8C67D.8080309@fedoraproject.org> References: <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <46B1C29B.9010109@gmail.com> <1186055497.28137.13.camel@oneill.fubar.dk> <1186509915.6256.55.camel@localhost.localdomain> <46B8BD2A.1090000@fedoraproject.org> <20070807185156.GA14152@nostromo.devel.redhat.com> <46B8C284.3060604@fedoraproject.org> <20070807191512.GA14637@nostromo.devel.redhat.com> <46B8C67D.8080309@fedoraproject.org> Message-ID: <20070807193353.GB14637@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: >>> Wasn't talking about myself but there are a number of x86_64 systems (and >>> want the x86_64 version of Fedora ) without a DVD drive out there. >> Surely you mean 'without an optical drive'. > > Are you referring to things like USB? I'm saying anything new enough to be x86_64 that has an optical drive is reasonably new enough to have a DVD-ROM. Bill From walters at redhat.com Tue Aug 7 19:37:13 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 07 Aug 2007 15:37:13 -0400 Subject: livecd hacking In-Reply-To: <200708071847.36297.ml@deadbabylon.de> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186077915.3435.3.camel@neutron.verbum.private> <200708031232.42374.ml@deadbabylon.de> <200708071847.36297.ml@deadbabylon.de> Message-ID: <1186515433.3674.12.camel@neutron.verbum.private> On Tue, 2007-08-07 at 18:47 +0200, Sebastian Vahl wrote: > Well, I didn't had much time. But these config is more closer to the normal > one. I removed only @games from livecd-desktop-minimal.ks and removed the > further not wanted packages in livecd-fedora-kde.ks. But the list is not > complete yet. # remove some packages from dekstop-minimal.ks -scim* -system-config-printer* -gdm -authconfig-gtk -m17n* -xorg-x11-fonts-* -xorg-x11-twm -PolicyKit-gnome -libbeagle -yelp -firefox -desktop-backgrounds-basic -gnome-doc-utils-stylesheets Almost all of this should go back into desktop-minimal; the goal there is basically just be gdm+twm+xterm; then this list would ideally just be -gdm +kdm From katzj at redhat.com Tue Aug 7 19:40:30 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 15:40:30 -0400 Subject: livecd hacking In-Reply-To: <1186515433.3674.12.camel@neutron.verbum.private> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186077915.3435.3.camel@neutron.verbum.private> <200708031232.42374.ml@deadbabylon.de> <200708071847.36297.ml@deadbabylon.de> <1186515433.3674.12.camel@neutron.verbum.private> Message-ID: <1186515630.11906.6.camel@localhost.localdomain> On Tue, 2007-08-07 at 15:37 -0400, Colin Walters wrote: > On Tue, 2007-08-07 at 18:47 +0200, Sebastian Vahl wrote: > > Well, I didn't had much time. But these config is more closer to the normal > > one. I removed only @games from livecd-desktop-minimal.ks and removed the > > further not wanted packages in livecd-fedora-kde.ks. But the list is not > > complete yet. > > # remove some packages from dekstop-minimal.ks > -scim* > -system-config-printer* > -gdm > -authconfig-gtk > -m17n* > -xorg-x11-fonts-* > -xorg-x11-twm > -PolicyKit-gnome > -libbeagle > -yelp > -firefox > -desktop-backgrounds-basic > -gnome-doc-utils-stylesheets > > Almost all of this should go back into desktop-minimal; the goal there > is basically just be gdm+twm+xterm; But with what sort of language support (that's the m17n and scim bits) > then this list would ideally just be > -gdm > +kdm It also looks somewhat resolved out -- I bet that the list could be shrunk somewhat -- yelp is probably the cause for libbeagle, firefox and perhaps more. Will look closer once I get through mail hell Jeremy From mclasen at redhat.com Tue Aug 7 19:43:48 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 07 Aug 2007 15:43:48 -0400 Subject: livecd hacking In-Reply-To: <1186515630.11906.6.camel@localhost.localdomain> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186077915.3435.3.camel@neutron.verbum.private> <200708031232.42374.ml@deadbabylon.de> <200708071847.36297.ml@deadbabylon.de> <1186515433.3674.12.camel@neutron.verbum.private> <1186515630.11906.6.camel@localhost.localdomain> Message-ID: <1186515829.3180.15.camel@localhost.localdomain> While we are busy removing stuff, can I also propose: -ImageMagick -tcsh Unless there are any hidden reasons for keeping these - I couldn't find any dependencies that would pull them in, and at least ImageMagick is not really small. From mclasen at redhat.com Tue Aug 7 19:47:46 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 07 Aug 2007 15:47:46 -0400 Subject: f8 desktop livecd In-Reply-To: <1186509927.6256.56.camel@localhost.localdomain> References: <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> <20070802161456.GA15802@nostromo.devel.redhat.com> <1186509927.6256.56.camel@localhost.localdomain> Message-ID: <1186516066.3180.18.camel@localhost.localdomain> On Tue, 2007-08-07 at 14:05 -0400, Jeremy Katz wrote: > On Thu, 2007-08-02 at 12:14 -0400, Bill Nottingham wrote: > > Jeff Spaleta (jspaleta at gmail.com) said: > > > On 8/2/07, Caolan McNamara wrote: > > > > Most companies have the luxury of a formal or informal big 7 or big 12 > > > > language policy, and e.g. Dzongkha and Irish can forget about being > > > > supported. I guess the ideal solution for something like fedora would be > > > > a set of regional cds, though I'm not enthusiastic about actually > > > > contributing constructively and doing the work :-) > > > > > > Are all the translations broken out into subpackages in sane way > > > across the distro? > > > > For OO.o and KDE, they are split. For other packages, they are not. > > Whether to split or not is a long, drawn-out conversation. (Basically, > > you make building liveCDs easier at the cost of making all languages > > Just Work much harder.) > > %{lang} tagging is simple enough to take advantage of with the live > images if we want. Just needs a) way to specify it (return of > langsupport!) and b) then actually setting the rpm macro. > I think it would be worthwhile to investigate this some more. I've started to add %lang tagging to all the big translated manuals in gnome packages, which should make this quite a bit more effective. From sundaram at fedoraproject.org Tue Aug 7 19:55:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 01:25:09 +0530 Subject: f8 desktop livecd In-Reply-To: <20070807193353.GB14637@nostromo.devel.redhat.com> References: <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <46B1C29B.9010109@gmail.com> <1186055497.28137.13.camel@oneill.fubar.dk> <1186509915.6256.55.camel@localhost.localdomain> <46B8BD2A.1090000@fedoraproject.org> <20070807185156.GA14152@nostromo.devel.redhat.com> <46B8C284.3060604@fedoraproject.org> <20070807191512.GA14637@nostromo.devel.redhat.com> <46B8C67D.8080309@fedoraproject.org> <20070807193353.GB14637@nostromo.devel.redhat.com> Message-ID: <46B8CE1D.5050307@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >>>> Wasn't talking about myself but there are a number of x86_64 systems (and >>>> want the x86_64 version of Fedora ) without a DVD drive out there. >>> Surely you mean 'without an optical drive'. >> Are you referring to things like USB? > > I'm saying anything new enough to be x86_64 that has an optical drive > is reasonably new enough to have a DVD-ROM. People keep saying that but end users are repeating coming up with instances where this isn't true at all. I just pointed this out to Jeremy earlier. https://www.redhat.com/archives/fedora-websites-list/2007-August/msg00020.html Follow fedora-list discussions or fedoraforum.org for more such instances. Rahul From katzj at redhat.com Tue Aug 7 19:53:43 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 15:53:43 -0400 Subject: livecd hacking In-Reply-To: <1186515829.3180.15.camel@localhost.localdomain> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186077915.3435.3.camel@neutron.verbum.private> <200708031232.42374.ml@deadbabylon.de> <200708071847.36297.ml@deadbabylon.de> <1186515433.3674.12.camel@neutron.verbum.private> <1186515630.11906.6.camel@localhost.localdomain> <1186515829.3180.15.camel@localhost.localdomain> Message-ID: <1186516423.11906.11.camel@localhost.localdomain> On Tue, 2007-08-07 at 15:43 -0400, Matthias Clasen wrote: > While we are busy removing stuff, can I also propose: > -ImageMagick Arguably, why is ImageMagick default anyway instead of optional in comps? The same could be asked for dcraw. Generally, graphics-support is graphical apps... the command line tools probably shouldn't be defaults. > -tcsh IIRC, there is something which gets unhappy without it, although my mind is blanking on what at the moment. Jeremy From notting at redhat.com Tue Aug 7 19:59:53 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Aug 2007 15:59:53 -0400 Subject: f8 desktop livecd In-Reply-To: <46B8CE1D.5050307@fedoraproject.org> References: <46B1C29B.9010109@gmail.com> <1186055497.28137.13.camel@oneill.fubar.dk> <1186509915.6256.55.camel@localhost.localdomain> <46B8BD2A.1090000@fedoraproject.org> <20070807185156.GA14152@nostromo.devel.redhat.com> <46B8C284.3060604@fedoraproject.org> <20070807191512.GA14637@nostromo.devel.redhat.com> <46B8C67D.8080309@fedoraproject.org> <20070807193353.GB14637@nostromo.devel.redhat.com> <46B8CE1D.5050307@fedoraproject.org> Message-ID: <20070807195953.GA13394@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > https://www.redhat.com/archives/fedora-websites-list/2007-August/msg00020.html That message does not contradict my point in any way. Please read carefully. Bill From notting at redhat.com Tue Aug 7 20:03:59 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Aug 2007 16:03:59 -0400 Subject: livecd hacking In-Reply-To: <1186516423.11906.11.camel@localhost.localdomain> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186077915.3435.3.camel@neutron.verbum.private> <200708031232.42374.ml@deadbabylon.de> <200708071847.36297.ml@deadbabylon.de> <1186515433.3674.12.camel@neutron.verbum.private> <1186515630.11906.6.camel@localhost.localdomain> <1186515829.3180.15.camel@localhost.localdomain> <1186516423.11906.11.camel@localhost.localdomain> Message-ID: <20070807200359.GB13394@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > On Tue, 2007-08-07 at 15:43 -0400, Matthias Clasen wrote: > > While we are busy removing stuff, can I also propose: > > -ImageMagick > > Arguably, why is ImageMagick default anyway instead of optional in > comps? The same could be asked for dcraw. Generally, graphics-support > is graphical apps... the command line tools probably shouldn't be > defaults. Fixed. > > -tcsh > > IIRC, there is something which gets unhappy without it, although my mind > is blanking on what at the moment. Then whatever it is should require it (also fixed). Bill From sundaram at fedoraproject.org Tue Aug 7 20:07:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 01:37:23 +0530 Subject: f8 desktop livecd In-Reply-To: <20070807195953.GA13394@nostromo.devel.redhat.com> References: <46B1C29B.9010109@gmail.com> <1186055497.28137.13.camel@oneill.fubar.dk> <1186509915.6256.55.camel@localhost.localdomain> <46B8BD2A.1090000@fedoraproject.org> <20070807185156.GA14152@nostromo.devel.redhat.com> <46B8C284.3060604@fedoraproject.org> <20070807191512.GA14637@nostromo.devel.redhat.com> <46B8C67D.8080309@fedoraproject.org> <20070807193353.GB14637@nostromo.devel.redhat.com> <46B8CE1D.5050307@fedoraproject.org> <20070807195953.GA13394@nostromo.devel.redhat.com> Message-ID: <46B8D0FB.2080804@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> https://www.redhat.com/archives/fedora-websites-list/2007-August/msg00020.html > > That message does not contradict my point in any way. Please read carefully. He has a x86_64 system with only a CD-RW drive which does seem to contradict what you said to me. How do you recommend that he install Fedora 7 if he doesn't have a high bandwidth connection? Rahul From notting at redhat.com Tue Aug 7 20:12:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Aug 2007 16:12:38 -0400 Subject: f8 desktop livecd In-Reply-To: <46B8D0FB.2080804@fedoraproject.org> References: <1186509915.6256.55.camel@localhost.localdomain> <46B8BD2A.1090000@fedoraproject.org> <20070807185156.GA14152@nostromo.devel.redhat.com> <46B8C284.3060604@fedoraproject.org> <20070807191512.GA14637@nostromo.devel.redhat.com> <46B8C67D.8080309@fedoraproject.org> <20070807193353.GB14637@nostromo.devel.redhat.com> <46B8CE1D.5050307@fedoraproject.org> <20070807195953.GA13394@nostromo.devel.redhat.com> <46B8D0FB.2080804@fedoraproject.org> Message-ID: <20070807201238.GC13394@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > He has a x86_64 system with only a CD-RW drive which does seem to > contradict what you said to me. How do you recommend that he install Fedora > 7 if he doesn't have a high bandwidth connection? His *burner* box isn't DVD - we realize we don't serve that market any way, and that's what the media projects are for. Bill From ml at deadbabylon.de Tue Aug 7 21:07:29 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 7 Aug 2007 23:07:29 +0200 Subject: livecd hacking In-Reply-To: <1186515630.11906.6.camel@localhost.localdomain> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186515433.3674.12.camel@neutron.verbum.private> <1186515630.11906.6.camel@localhost.localdomain> Message-ID: <200708072307.38434.ml@deadbabylon.de> Am Di 7.August 2007 schrieb Jeremy Katz: > On Tue, 2007-08-07 at 15:37 -0400, Colin Walters wrote: > > On Tue, 2007-08-07 at 18:47 +0200, Sebastian Vahl wrote: > > > Well, I didn't had much time. But these config is more closer to the > > > normal one. I removed only @games from livecd-desktop-minimal.ks and > > > removed the further not wanted packages in livecd-fedora-kde.ks. But > > > the list is not complete yet. > > > > # remove some packages from dekstop-minimal.ks > > -scim* > > -system-config-printer* > > -gdm > > -authconfig-gtk > > -m17n* > > -xorg-x11-fonts-* > > -xorg-x11-twm > > -PolicyKit-gnome > > -libbeagle > > -yelp > > -firefox > > -desktop-backgrounds-basic > > -gnome-doc-utils-stylesheets > > > > Almost all of this should go back into desktop-minimal; the goal there > > is basically just be gdm+twm+xterm; > > But with what sort of language support (that's the m17n and scim bits) > > > then this list would ideally just be > > -gdm > > +kdm > > It also looks somewhat resolved out -- I bet that the list could be > shrunk somewhat -- yelp is probably the cause for libbeagle, firefox and > perhaps more. Will look closer once I get through mail hell It seems to be this way: anaconda -> zenity -> yelp -> firefox, libbeagle Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Tue Aug 7 21:41:01 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 17:41:01 -0400 Subject: livecd hacking In-Reply-To: <200708072307.38434.ml@deadbabylon.de> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186515433.3674.12.camel@neutron.verbum.private> <1186515630.11906.6.camel@localhost.localdomain> <200708072307.38434.ml@deadbabylon.de> Message-ID: <1186522861.11906.87.camel@localhost.localdomain> On Tue, 2007-08-07 at 23:07 +0200, Sebastian Vahl wrote: > Am Di 7.August 2007 schrieb Jeremy Katz: > > It also looks somewhat resolved out -- I bet that the list could be > > shrunk somewhat -- yelp is probably the cause for libbeagle, firefox and > > perhaps more. Will look closer once I get through mail hell > > It seems to be this way: anaconda -> zenity -> yelp -> firefox, libbeagle Aha, so due to anaconda's trying out zenity to see if it gives us a way for people to give feedback during %post. Although it's not clear to me why zenity now depends on yelp. Jeremy From sundaram at fedoraproject.org Tue Aug 7 21:46:02 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 03:16:02 +0530 Subject: Tracker by default in Fedora 8? Message-ID: <46B8E81A.7050102@fedoraproject.org> Hi While Tracker has always been faster than Beagle and without the memory leaks, previous versions were lacking in features. Tracker 0.6 (http://jamiemcc.livejournal.com/8837.html) has a number of improvements making it more or less reached feature parity with Beagle which we dropped out by default in Fedora 7. Tracker is also going to be the default in the next version of Ubuntu. What do folks think about installing and enabling Tracker by default in Fedora 8? Rahul From mclasen at redhat.com Tue Aug 7 21:53:06 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 07 Aug 2007 17:53:06 -0400 Subject: livecd hacking In-Reply-To: <1186522861.11906.87.camel@localhost.localdomain> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186515433.3674.12.camel@neutron.verbum.private> <1186515630.11906.6.camel@localhost.localdomain> <200708072307.38434.ml@deadbabylon.de> <1186522861.11906.87.camel@localhost.localdomain> Message-ID: <1186523586.3180.20.camel@localhost.localdomain> On Tue, 2007-08-07 at 17:41 -0400, Jeremy Katz wrote: > On Tue, 2007-08-07 at 23:07 +0200, Sebastian Vahl wrote: > > Am Di 7.August 2007 schrieb Jeremy Katz: > > > It also looks somewhat resolved out -- I bet that the list could be > > > shrunk somewhat -- yelp is probably the cause for libbeagle, firefox and > > > perhaps more. Will look closer once I get through mail hell > > > > It seems to be this way: anaconda -> zenity -> yelp -> firefox, libbeagle > > Aha, so due to anaconda's trying out zenity to see if it gives us a way > for people to give feedback during %post. Although it's not clear to me > why zenity now depends on yelp. Thats directory dependencies for you. Everything that installs help in /usr/share/gnome/help depends on yelp... From walters at redhat.com Tue Aug 7 21:58:13 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 07 Aug 2007 17:58:13 -0400 Subject: Tracker by default in Fedora 8? In-Reply-To: <46B8E81A.7050102@fedoraproject.org> References: <46B8E81A.7050102@fedoraproject.org> Message-ID: <1186523893.3674.49.camel@neutron.verbum.private> On Wed, 2007-08-08 at 03:16 +0530, Rahul Sundaram wrote: > Hi > > While Tracker has always been faster than Beagle and without the memory > leaks, previous versions were lacking in features. Tracker 0.6 > (http://jamiemcc.livejournal.com/8837.html) has a number of improvements > making it more or less reached feature parity with Beagle which we > dropped out by default in Fedora 7. Tracker is also going to be the > default in the next version of Ubuntu. > > What do folks think about installing and enabling Tracker by default in > Fedora 8? Personally - I'm a bit skeptical of Tracker actually being better than Beagle. I don't have anything substantial, but my instinct on this is that writing a desktop search engine is actually really hard - not barfing on bad files (inherent tension with supporting lots of file types), figuring out all the touchy details of when to do the indexing[1], etc., and that unlike Beagle, Tracker actually hasn't seen wide deployment so it hasn't yet been truly tested. [1] screensaver integration, am I playing a performance-hungry game, did I just create a new file I might want to find, etc. From sundaram at fedoraproject.org Tue Aug 7 22:05:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 03:35:04 +0530 Subject: livecd hacking In-Reply-To: <1186523586.3180.20.camel@localhost.localdomain> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186515433.3674.12.camel@neutron.verbum.private> <1186515630.11906.6.camel@localhost.localdomain> <200708072307.38434.ml@deadbabylon.de> <1186522861.11906.87.camel@localhost.localdomain> <1186523586.3180.20.camel@localhost.localdomain> Message-ID: <46B8EC90.9050801@fedoraproject.org> Matthias Clasen wrote: > On Tue, 2007-08-07 at 17:41 -0400, Jeremy Katz wrote: >> On Tue, 2007-08-07 at 23:07 +0200, Sebastian Vahl wrote: >>> Am Di 7.August 2007 schrieb Jeremy Katz: >>>> It also looks somewhat resolved out -- I bet that the list could be >>>> shrunk somewhat -- yelp is probably the cause for libbeagle, firefox and >>>> perhaps more. Will look closer once I get through mail hell >>> It seems to be this way: anaconda -> zenity -> yelp -> firefox, libbeagle >> Aha, so due to anaconda's trying out zenity to see if it gives us a way >> for people to give feedback during %post. Although it's not clear to me >> why zenity now depends on yelp. > > Thats directory dependencies for you. > Everything that installs help in /usr/share/gnome/help depends on > yelp... This is not very sane. Can we get this package fixed? In reasonably cases, the ownership guideline can have exceptions. Rahul From drago01 at gmail.com Tue Aug 7 22:12:51 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 8 Aug 2007 00:12:51 +0200 Subject: Tracker by default in Fedora 8? In-Reply-To: <46B8E81A.7050102@fedoraproject.org> References: <46B8E81A.7050102@fedoraproject.org> Message-ID: On 8/7/07, Rahul Sundaram wrote: > > Hi > > While Tracker has always been faster than Beagle and without the memory > leaks, previous versions were lacking in features. Tracker 0.6 > (http://jamiemcc.livejournal.com/8837.html) has a number of improvements > making it more or less reached feature parity with Beagle which we > dropped out by default in Fedora 7. Tracker is also going to be the > default in the next version of Ubuntu. > > What do folks think about installing and enabling Tracker by default in > Fedora 8? why do you think is tracker better than beagle? its true that it uses less memory but I doubt its any different about i/o and cpu usage. and does it stop indexing when running on battery? beagle does this. also with the cfs scheduler the impact on the system due to high cpu usage should be less. the only remaining part is i/o and I open a thread on lkml about allowing non root user to set the i/o prio to idle. beagle already tryes to do this but fails because it don't have the permission to do so. Removing the check from the kernel is easy but there is a discussion on what idle task can to to the system and if its safe to allow it for non root users. if the kernel gets this change I would opt for re enabling beagle and see what it does. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Tue Aug 7 22:37:26 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Aug 2007 14:37:26 -0800 Subject: Tracker by default in Fedora 8? In-Reply-To: <1186523893.3674.49.camel@neutron.verbum.private> References: <46B8E81A.7050102@fedoraproject.org> <1186523893.3674.49.camel@neutron.verbum.private> Message-ID: <604aa7910708071537k6fb0da25ge213b14e93423df5@mail.gmail.com> On 8/7/07, Colin Walters wrote: > Personally - I'm a bit skeptical of Tracker actually being better than > Beagle. I don't have anything substantial, but my instinct on this is > that writing a desktop search engine is actually really hard - not > barfing on bad files (inherent tension with supporting lots of file > types), figuring out all the touchy details of when to do the > indexing[1], etc., and that unlike Beagle, Tracker actually hasn't seen > wide deployment so it hasn't yet been truly tested. I don't expect any implementation of an indexer to be perfect. But what I desperately need, is an implementation that expects to run into problems and knows how to communicate back to the users when it runs into a problem indexing a file... so we can attempt to actually report something credible and reproducible. My biggest beef with beagle wasn't that it sat there and chewed system resources. My biggest beef with beagle was that there was no obvious feedback to a user nor a way to query what the exact nature of the problem is while its happening. if tracker doesn't do a better job of problem feedback, it's not going to taste better. -jef From sundaram at fedoraproject.org Tue Aug 7 22:41:30 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 04:11:30 +0530 Subject: Tracker by default in Fedora 8? In-Reply-To: References: <46B8E81A.7050102@fedoraproject.org> Message-ID: <46B8F51A.2070308@fedoraproject.org> dragoran wrote: > > why do you think is tracker better than beagle? > its true that it uses less memory but I doubt its any different about > i/o and cpu usage. It is. Run them both and see for yourself. The performance, cpu usage and the speed of the indexer is very different between them. > and does it stop indexing when running on battery? beagle does this. I don't know. It should be easy enough to add if it doesn't. File a RFE. Rahul From sundaram at fedoraproject.org Tue Aug 7 22:50:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 04:20:41 +0530 Subject: Tracker by default in Fedora 8? In-Reply-To: <1186523893.3674.49.camel@neutron.verbum.private> References: <46B8E81A.7050102@fedoraproject.org> <1186523893.3674.49.camel@neutron.verbum.private> Message-ID: <46B8F741.8080005@fedoraproject.org> Colin Walters wrote: > Personally - I'm a bit skeptical of Tracker actually being better than > Beagle. I don't have anything substantial, but my instinct on this is > that writing a desktop search engine is actually really hard - not > barfing on bad files (inherent tension with supporting lots of file > types), figuring out all the touchy details of when to do the > indexing[1], etc., and that unlike Beagle, Tracker actually hasn't seen > wide deployment so it hasn't yet been truly tested. If testing is the only major issue, it is already in the devel branch of Ubuntu by default so it should get some good testing there and we can just enable it in rawhide - wait and watch the results and decide before the general release of Fedora 8. Beagle doesn't seem to be actively maintained in Fedora, not installed by default anymore and we don't seem to have enough mono expertise. Not having these saves a good amount of space in the live images too. If you still consider Beagle as the better choice, let's enable it back in rawhide by default then. Either way, desktop search is a good thing to have by default. Rahul From drago01 at gmail.com Tue Aug 7 23:04:38 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 8 Aug 2007 01:04:38 +0200 Subject: Tracker by default in Fedora 8? In-Reply-To: <46B8F51A.2070308@fedoraproject.org> References: <46B8E81A.7050102@fedoraproject.org> <46B8F51A.2070308@fedoraproject.org> Message-ID: On 8/8/07, Rahul Sundaram wrote: > > dragoran wrote: > > > > > why do you think is tracker better than beagle? > > its true that it uses less memory but I doubt its any different about > > i/o and cpu usage. > > It is. Run them both and see for yourself. The performance, cpu usage > and the speed of the indexer is very different between them. sure will test tracker only used a early version but havn't lokked at recent releases. > and does it stop indexing when running on battery? beagle does this. > > I don't know. It should be easy enough to add if it doesn't. File a RFE. shouldn't be hard to add but this is a blocker for enabling it by default. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mclasen at redhat.com Tue Aug 7 23:11:40 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 07 Aug 2007 19:11:40 -0400 Subject: Tracker by default in Fedora 8? In-Reply-To: <46B8E81A.7050102@fedoraproject.org> References: <46B8E81A.7050102@fedoraproject.org> Message-ID: <1186528300.3180.23.camel@localhost.localdomain> On Wed, 2007-08-08 at 03:16 +0530, Rahul Sundaram wrote: > What do folks think about installing and enabling Tracker by default in > Fedora 8? I guess we need a fully filled out and approved feature page for that. Shouldn't take more than 10 minutes... :-) From sundaram at fedoraproject.org Tue Aug 7 23:18:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Aug 2007 04:48:33 +0530 Subject: Tracker by default in Fedora 8? In-Reply-To: <1186528300.3180.23.camel@localhost.localdomain> References: <46B8E81A.7050102@fedoraproject.org> <1186528300.3180.23.camel@localhost.localdomain> Message-ID: <46B8FDC9.1030608@fedoraproject.org> Matthias Clasen wrote: > On Wed, 2007-08-08 at 03:16 +0530, Rahul Sundaram wrote: > >> What do folks think about installing and enabling Tracker by default in >> Fedora 8? > > I guess we need a fully filled out and approved feature page for that. > Shouldn't take more than 10 minutes... :-) I guess you didn't read the feature process. A spec needs a owner before it gets approved ;-) A discussion on whether you want to do it or not doesn't need a spec anyway. Discuss it, evaluate it and make a decision first. Rahul From bnocera at redhat.com Wed Aug 8 18:06:24 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 08 Aug 2007 19:06:24 +0100 Subject: Tracker by default in Fedora 8? In-Reply-To: <46B8E81A.7050102@fedoraproject.org> References: <46B8E81A.7050102@fedoraproject.org> Message-ID: <1186596384.3711.26.camel@cookie.hadess.net> On Wed, 2007-08-08 at 03:16 +0530, Rahul Sundaram wrote: > Hi > > While Tracker has always been faster than Beagle and without the memory > leaks, previous versions were lacking in features. Tracker 0.6 > (http://jamiemcc.livejournal.com/8837.html) has a number of improvements > making it more or less reached feature parity with Beagle which we > dropped out by default in Fedora 7. Tracker is also going to be the > default in the next version of Ubuntu. > > What do folks think about installing and enabling Tracker by default in > Fedora 8? I think the code is dreadful. I'd rather try and hunt a packager in the community (easy), as well as a developer/upstream person for Beagle to make sure bugs are tracked, and regressions are avoided. From b2.mdr.magarzo at gmail.com Thu Aug 9 00:32:49 2007 From: b2.mdr.magarzo at gmail.com (M Daniel R Magarzo) Date: Thu, 09 Aug 2007 02:32:49 +0200 Subject: Tracker by default in Fedora 8? In-Reply-To: <46B8F741.8080005@fedoraproject.org> References: <46B8E81A.7050102@fedoraproject.org> <1186523893.3674.49.camel@neutron.verbum.private> <46B8F741.8080005@fedoraproject.org> Message-ID: <1186619569.8783.31.camel@Ulises> El mi?, 08-08-2007 a las 04:20 +0530, Rahul Sundaram escribi?: > If you > still consider Beagle as the better choice, let's enable it back in > rawhide by default then. > > Either way, desktop search is a good thing to have by default. I'm a lurker here in this list, but I couldn't avoid getting into this thread at this point. Just my particular experience, just an end-user: * I ended up removing beagle from F7 here (too..) * It's scandalous the amount of CPU usage that such a thing eats continuously in the background. I'm not much hardened in Linux, but just by doing a single "top" at the CLI we will always find beagle at the top.. * Beagle, and other things such as tomboy drag others like Mono, too much weight... IMO. * I can't see clearly its (acclaimed) benefits and goodness. It isn't worthwhile, at least for me.. * I can't understand "the fashion" about that tool, I've even heard (read) that at the moment it's ("should be") one of the "five priorities" for the desktop, "which would be able to ensure the success of this or that Linux flavour.." * I use "gnome-search" and I think it's a powerful tool. I'm happy with it. * I don't know "tracker", but I hope it works & it does it with no too much cpu load. Daniel From sundaram at fedoraproject.org Thu Aug 9 13:05:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 09 Aug 2007 18:35:47 +0530 Subject: Tracker by default in Fedora 8? In-Reply-To: <1186619569.8783.31.camel@Ulises> References: <46B8E81A.7050102@fedoraproject.org> <1186523893.3674.49.camel@neutron.verbum.private> <46B8F741.8080005@fedoraproject.org> <1186619569.8783.31.camel@Ulises> Message-ID: <46BB112B.1010307@fedoraproject.org> M Daniel R Magarzo wrote: > * I use "gnome-search" and I think it's a powerful tool. I'm happy with > it. > * I don't know "tracker", but I hope it works & it does it with no too > much cpu load. Try it out and let us know what you think. Rahul From walters at redhat.com Thu Aug 9 16:38:18 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 09 Aug 2007 12:38:18 -0400 Subject: livecd hacking In-Reply-To: <1186511302.6256.72.camel@localhost.localdomain> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186511302.6256.72.camel@localhost.localdomain> Message-ID: <1186677498.3187.20.camel@neutron.verbum.private> On Tue, 2007-08-07 at 14:28 -0400, Jeremy Katz wrote: > At a glance, this part looks reasonable. Need to fix up %include so > that it doesn't depend on the working directory. But that looks pretty > trivial -- we just need to subclass KickstartParser and override > readKickstart() with a method that finds the file. Otherwise, people > will hit what svahl did. Looks like you fixed this one. Should we try to iterate the changes to the kickstart files, or do you want to just look at the patches in the git repository? From katzj at redhat.com Thu Aug 9 16:45:12 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 09 Aug 2007 12:45:12 -0400 Subject: livecd hacking In-Reply-To: <1186677498.3187.20.camel@neutron.verbum.private> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186511302.6256.72.camel@localhost.localdomain> <1186677498.3187.20.camel@neutron.verbum.private> Message-ID: <1186677913.26986.6.camel@erebor.boston.redhat.com> On Thu, 2007-08-09 at 12:38 -0400, Colin Walters wrote: > On Tue, 2007-08-07 at 14:28 -0400, Jeremy Katz wrote: > > At a glance, this part looks reasonable. Need to fix up %include so > > that it doesn't depend on the working directory. But that looks pretty > > trivial -- we just need to subclass KickstartParser and override > > readKickstart() with a method that finds the file. Otherwise, people > > will hit what svahl did. > > Looks like you fixed this one. Should we try to iterate the changes to > the kickstart files, or do you want to just look at the patches in the > git repository? Yeah, seemed like a fun thing to throw together a fix for. As for the kickstart files, I was going to take a look hopefully a little later today or tomorrow and get them in. Iterating patches to them on fedora-livecd-list is, in general, less interesting (at least, imho). Jeremy From b2.mdr.magarzo at gmail.com Thu Aug 9 21:09:40 2007 From: b2.mdr.magarzo at gmail.com (M Daniel R Magarzo) Date: Thu, 09 Aug 2007 23:09:40 +0200 Subject: Tracker by default in Fedora 8? In-Reply-To: <46BB112B.1010307@fedoraproject.org> References: <46B8E81A.7050102@fedoraproject.org> <1186523893.3674.49.camel@neutron.verbum.private> <46B8F741.8080005@fedoraproject.org> <1186619569.8783.31.camel@Ulises> <46BB112B.1010307@fedoraproject.org> Message-ID: <1186693780.14161.15.camel@Ulises> El jue, 09-08-2007 a las 18:35 +0530, Rahul Sundaram escribi?: > M Daniel R Magarzo wrote: > > > * I use "gnome-search" and I think it's a powerful tool. I'm happy with > > it. > > * I don't know "tracker", but I hope it works & it does it with no too > > much cpu load. > > Try it out and let us know what you think. > > Rahul > Tried. Faster, more powerful, tidy interface when showing results, indexing deeply and it does not last eternally, just a few seconds/minutes. Doing a "top" reveals that there isn't "an alien chewing into our stomach" anymore.. Tracker goes smoothly without doubt. Preferences panel shouldn't go split from the main interface though, IMO. Daniel From sundaram at fedoraproject.org Thu Aug 9 21:59:19 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 10 Aug 2007 03:29:19 +0530 Subject: Tracker by default in Fedora 8? In-Reply-To: <1186693780.14161.15.camel@Ulises> References: <46B8E81A.7050102@fedoraproject.org> <1186523893.3674.49.camel@neutron.verbum.private> <46B8F741.8080005@fedoraproject.org> <1186619569.8783.31.camel@Ulises> <46BB112B.1010307@fedoraproject.org> <1186693780.14161.15.camel@Ulises> Message-ID: <46BB8E37.1030305@fedoraproject.org> M Daniel R Magarzo wrote: > > > Tried. > > Faster, more powerful, tidy interface when showing results, indexing > deeply and it does not last eternally, just a few seconds/minutes. Doing > a "top" reveals that there isn't "an alien chewing into our stomach" > anymore.. Tracker goes smoothly without doubt. > > Preferences panel shouldn't go split from the main interface though, > IMO. Thanks for the feedback. I agree about the preferences disconnect. Please file a RFE preferably on GNOME bugzilla. Rahul From lixbt5 at china.com.cn Fri Aug 10 05:15:59 2007 From: lixbt5 at china.com.cn (bentao) Date: Fri, 10 Aug 2007 13:15:59 +0800 Subject: (no subject) References: <20070809160022.C9E06735E6@hormel.redhat.com> Message-ID: help -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at gamesplace.info Fri Aug 10 12:59:34 2007 From: martin at gamesplace.info (Martin =?ISO-8859-1?Q?J=FCrgens?=) Date: Fri, 10 Aug 2007 14:59:34 +0200 Subject: How friendly are the configuration tools to end users? Message-ID: <1186750774.3001.7.camel@localhost6.localdomain6> Hi! Linux and especially Fedora is more and more used as a desktop operating system for end users. This creates new conditions how Fedora should look like. On the one hand, there are administrators, which want to have powerful GUI configuration applications. On the other hand, there is a new aspect, the end user. He probably does not know what IPv6 and other things are and just wants to configure a printer or network or the yum frontend. All in one, system administrators have other exceptations than end users. I am of the opinion that we somehow have to make both groups happy or make end users more happy without bothering system administrators. One way is to create seperate configuration tools for both groups, but I do not like that (SuSE does it slightly like that: YaST for administrators, the GNOME configuration tools for end users). An other, easy possibility would be to hide advanced configuration options behind a button "advanced". I know that this is not very specified yet, but maybe we can discuss about the problem and possible solutions. What do you think? Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From tiagomatos at gmail.com Fri Aug 10 13:42:03 2007 From: tiagomatos at gmail.com (Rui Tiago =?ISO-8859-1?Q?Ca=E7=E3o?= Matos) Date: Fri, 10 Aug 2007 14:42:03 +0100 Subject: How friendly are the configuration tools to end users? In-Reply-To: <1186750774.3001.7.camel@localhost6.localdomain6> References: <1186750774.3001.7.camel@localhost6.localdomain6> Message-ID: <1186753323.3090.1.camel@hive> On Sex, 2007-08-10 at 14:59 +0200, Martin J?rgens wrote: > Hi! > > Linux and especially Fedora is more and more used as a desktop operating > system for end users. > > This creates new conditions how Fedora should look like. On the one hand, there are > administrators, which want to have powerful GUI configuration applications. > > On the other hand, there is a new aspect, the end user. He probably does not know what IPv6 and other things are and just wants to configure a printer or > network or the yum frontend. All in one, system administrators have other exceptations than end users. > > I am of the opinion that we somehow have to make both groups happy or make end users more happy without bothering system administrators. > > One way is to create seperate configuration tools for both groups, but I do not like that (SuSE does it slightly like that: YaST for administrators, > the GNOME configuration tools for end users). An other, easy possibility would be to hide advanced configuration options behind a button "advanced". > > I know that this is not very specified yet, but maybe we can discuss about the problem and possible solutions. > > > What do you think? See this page and especially Murray Cumming's remarks at the end of it: http://live.gnome.org/ScratchPad/Configuration Cheers, Rui -------------- 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 davidz at redhat.com Mon Aug 13 16:10:02 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 13 Aug 2007 12:10:02 -0400 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <1185920349.12650.4.camel@neutron.verbum.private> References: <1185920349.12650.4.camel@neutron.verbum.private> Message-ID: <1187021402.2998.12.camel@oneill.fubar.dk> Hi, One thing we probably want on the desktop live cd, compared to mainline Fedora, is making sure that the user's home directory are world-executable, e.g. like this $ ls -l /home/ drwx--x--x 21 bateman bateman 4096 2007-08-12 19:01 bateman drwx--x--x 22 bundy bundy 4096 2007-07-28 19:01 bundy drwx--x--x 21 charles charles 4096 2007-07-28 18:24 charles drwx--x--x 42 davidz davidz 4096 2007-08-13 10:39 davidz With this, the ~/.face files should be readable by other users meaning that the fast-user-switch applet in a given session can read ~/.face from other users (this is because the "About Me" capplet specifically uses the rw-r--r-- permissions when creating that file). Which means you'll get a nice list with the appropriate icons http://people.freedesktop.org/~david/f-u-s-all-faces.png Changing the mode on newly created home directories can, I believe, be achieved by rewriting /etc/login.defs such that UMASK is set to 066 instead of 077 (I haven't tested this though). Probably worth adding some sed invocation in the %post of the live cd kickstart file. Jeremy, Colin? Btw, in the same vein, we probably want ~/Public to be created with mode rwxr-xr-x as well; I believe that requires a patch to xdg-user-dirs such that the mode can be specified in /etc/xdg/user-dirs.defaults. Longer term we should probably make ~/Public of other users visible somewhere and integrate it into the file manager or whatever. Alex? David From katzj at redhat.com Mon Aug 13 16:50:47 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 13 Aug 2007 12:50:47 -0400 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <1187021402.2998.12.camel@oneill.fubar.dk> References: <1185920349.12650.4.camel@neutron.verbum.private> <1187021402.2998.12.camel@oneill.fubar.dk> Message-ID: <1187023847.4921.14.camel@localhost.localdomain> On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote: > One thing we probably want on the desktop live cd, compared to mainline > Fedora, is making sure that the user's home directory are > world-executable, e.g. like this [snip] > Changing the mode on newly created home directories can, I believe, be > achieved by rewriting /etc/login.defs such that UMASK is set to 066 > instead of 077 (I haven't tested this though). Probably worth adding > some sed invocation in the %post of the live cd kickstart file. Jeremy, > Colin? >From a quick test, it looks like it works. And sed -i 's/UMASK *077/UMASK 066/g' /etc/login.defs seems like a workable sed invocation. If no one sees a reason not to, I'll get this added later (hoping to get Colin's abstraction bits in first) Jeremy From jrb at redhat.com Mon Aug 13 19:38:52 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Mon, 13 Aug 2007 15:38:52 -0400 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <1187021402.2998.12.camel@oneill.fubar.dk> References: <1185920349.12650.4.camel@neutron.verbum.private> <1187021402.2998.12.camel@oneill.fubar.dk> Message-ID: <1187033932.2729.114.camel@localhost.localdomain> On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote: > Hi, > > One thing we probably want on the desktop live cd, compared to mainline > Fedora, is making sure that the user's home directory are > world-executable, e.g. like this It's less of a low-hanging fruit, but I would love to also see us give every new account a random icon by default. It would be much cooler to see that than the question-mark silhouette. Thanks, -Jonathan From katzj at redhat.com Mon Aug 13 19:56:06 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 13 Aug 2007 15:56:06 -0400 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <1187033932.2729.114.camel@localhost.localdomain> References: <1185920349.12650.4.camel@neutron.verbum.private> <1187021402.2998.12.camel@oneill.fubar.dk> <1187033932.2729.114.camel@localhost.localdomain> Message-ID: <1187034966.4921.28.camel@localhost.localdomain> On Mon, 2007-08-13 at 15:38 -0400, Jonathan Blandford wrote: > On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote: > > One thing we probably want on the desktop live cd, compared to mainline > > Fedora, is making sure that the user's home directory are > > world-executable, e.g. like this > > It's less of a low-hanging fruit, but I would love to also see us give > every new account a random icon by default. It would be much cooler to > see that than the question-mark silhouette. random requires useradd hacking... something other than the question mark just requires dropping something in /etc/skel... Jeremy From davidz at redhat.com Mon Aug 13 20:10:31 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 13 Aug 2007 16:10:31 -0400 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <1187034966.4921.28.camel@localhost.localdomain> References: <1185920349.12650.4.camel@neutron.verbum.private> <1187021402.2998.12.camel@oneill.fubar.dk> <1187033932.2729.114.camel@localhost.localdomain> <1187034966.4921.28.camel@localhost.localdomain> Message-ID: <1187035831.6196.15.camel@oneill.fubar.dk> On Mon, 2007-08-13 at 15:56 -0400, Jeremy Katz wrote: > On Mon, 2007-08-13 at 15:38 -0400, Jonathan Blandford wrote: > > On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote: > > > One thing we probably want on the desktop live cd, compared to mainline > > > Fedora, is making sure that the user's home directory are > > > world-executable, e.g. like this > > > > It's less of a low-hanging fruit, but I would love to also see us give > > every new account a random icon by default. It would be much cooler to > > see that than the question-mark silhouette. > > random requires useradd hacking... something other than the question > mark just requires dropping something in /etc/skel... Ideally we'd just ask questions like these (plus preselecting a suitable random one) as part of the installation process including using GNOME Cheese / ktuberling / etc. style apps available. Other things I'd like to see is the ability to select the desktop background / color scheme / whatever. It's also a nice place to plug in migration tools to fetch this data from another OS / whatever. Also, it's preferable to do this at install time rather than firstboot time. Because I'm not so sure firstboot makes a lot of sense for a desktop/laptop targeted OS (though I'm sure it's great for enterprise workstation deployments). In addition, ideally the user can do this while the bits are being moved to his hard disk. David From mzerqung at 0pointer.de Mon Aug 13 20:35:12 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 13 Aug 2007 22:35:12 +0200 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <1187034966.4921.28.camel@localhost.localdomain> References: <1185920349.12650.4.camel@neutron.verbum.private> <1187021402.2998.12.camel@oneill.fubar.dk> <1187033932.2729.114.camel@localhost.localdomain> <1187034966.4921.28.camel@localhost.localdomain> Message-ID: <20070813203512.GA20738@tango.0pointer.de> On Mon, 13.08.07 15:56, Jeremy Katz (katzj at redhat.com) wrote: > > On Mon, 2007-08-13 at 15:38 -0400, Jonathan Blandford wrote: > > On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote: > > > One thing we probably want on the desktop live cd, compared to mainline > > > Fedora, is making sure that the user's home directory are > > > world-executable, e.g. like this > > > > It's less of a low-hanging fruit, but I would love to also see us give > > every new account a random icon by default. It would be much cooler to > > see that than the question-mark silhouette. > > random requires useradd hacking... Does it? You could just create ~/.faces on first login if it doesn't exist and select a random face then. Should be trivial. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From katzj at redhat.com Mon Aug 13 20:42:48 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 13 Aug 2007 16:42:48 -0400 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <20070813203512.GA20738@tango.0pointer.de> References: <1185920349.12650.4.camel@neutron.verbum.private> <1187021402.2998.12.camel@oneill.fubar.dk> <1187033932.2729.114.camel@localhost.localdomain> <1187034966.4921.28.camel@localhost.localdomain> <20070813203512.GA20738@tango.0pointer.de> Message-ID: <1187037768.4921.36.camel@localhost.localdomain> On Mon, 2007-08-13 at 22:35 +0200, Lennart Poettering wrote: > On Mon, 13.08.07 15:56, Jeremy Katz (katzj at redhat.com) wrote: > > random requires useradd hacking... > > Does it? You could just create ~/.faces on first login if it doesn't > exist and select a random face then. Should be trivial. Duh. Some days, I think too hard :-) Jeremy From mclasen at redhat.com Tue Aug 14 13:02:10 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 14 Aug 2007 09:02:10 -0400 Subject: f8 desktop livecd In-Reply-To: <1186509927.6256.56.camel@localhost.localdomain> References: <1185991239.2822.45.camel@oneill.fubar.dk> <1185993793.3123.31.camel@neutron.verbum.private> <20070801144635.5c2c361c@localhost.localdomain> <1185995005.3123.43.camel@neutron.verbum.private> <1186040325.3239.3.camel@Nom> <20070802073453.793671ad@ender> <1186058008.3239.70.camel@Nom> <20070802093634.785c9f0d@localhost.localdomain> <1186063114.3239.88.camel@Nom> <604aa7910708020912s698677dcodfd36f7672879ee8@mail.gmail.com> <20070802161456.GA15802@nostromo.devel.redhat.com> <1186509927.6256.56.camel@localhost.localdomain> Message-ID: <1187096530.4039.13.camel@localhost.localdomain> On Tue, 2007-08-07 at 14:05 -0400, Jeremy Katz wrote: > %{lang} tagging is simple enough to take advantage of with the live > images if we want. Just needs a) way to specify it (return of > langsupport!) and b) then actually setting the rpm macro. > > You're kind of screwed if you ever want to add more translations, but > that is a tradeoff that could be made. But the discussion about that is > going on in a different thread too :-) > After Panu showed the necessary queryformat magic in the other thread, I actually sat down to see how hard it is to get the necessary information out of rpm to do that. The result is a very rough shell script that spits out a list of packages that you need to reinstall when _install_langs changes. This is just a proto-prototype: - You can probably do the same thing much better in python - A real solution must handle language support groups as well - I don't know if this approach will work for removal of languages, too. (Does --replacepkg ever remove files ?) - It would probably be better to use a dedicated /etc/rpm/macros.lang file - An actual implementation must decide where to expose this functionality: in pirut, since it is about installing packages or in s-c-language, since it is about language support ? Maybe this inspires somebody to work on an actual implementation. Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: install-lang.sh Type: application/x-shellscript Size: 1332 bytes Desc: not available URL: From mclasen at redhat.com Wed Aug 15 01:23:59 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 14 Aug 2007 21:23:59 -0400 Subject: Meet the desktop team Message-ID: <1187141039.3199.21.camel@localhost.localdomain> There have been some discussions on fedora-desktop-list recently about making the desktop livecd spin a better desktop. We (the RH desktop team) would like to take this on, by taking "editorial control" of the desktop livecd spin, and transforming it into an awesome desktop. We'd like to start holding regular public irc meetings -- "meet the desktop team", if you want. The official form in which this happens in Fedora is in a SIG, so we will form a "Desktop SIG" and invite interested members of the Fedora community to work with us on making the Fedora desktop spin the best desktop in its class. The first meeting is going to take place in the #fedora-meeting irc channel on Freenode, Wednesday, 18:00-19:00 UTC (2pm-3pm EDT) (see http://fedoraproject.org/wiki/Communicate#IRC) Proposed agenda for the first meeting: - Organizational questions - Goals and scope of the Desktop SIG - Concrete plans for the F8 desktop spin - Longer-term plans We have put our ideas for second agenda item up at http://www.fedoraproject.org/wiki/SIGs/Desktop Hope to see you tomorrow, Matthias From jon.nettleton at gmail.com Wed Aug 15 12:12:53 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 15 Aug 2007 08:12:53 -0400 Subject: Tracker by default in Fedora 8? In-Reply-To: <46BB8E37.1030305@fedoraproject.org> References: <46B8E81A.7050102@fedoraproject.org> <1186523893.3674.49.camel@neutron.verbum.private> <46B8F741.8080005@fedoraproject.org> <1186619569.8783.31.camel@Ulises> <46BB112B.1010307@fedoraproject.org> <1186693780.14161.15.camel@Ulises> <46BB8E37.1030305@fedoraproject.org> Message-ID: On 8/9/07, Rahul Sundaram wrote: > > M Daniel R Magarzo wrote: > > > > > > > Tried. > > > > Faster, more powerful, tidy interface when showing results, indexing > > deeply and it does not last eternally, just a few seconds/minutes. Doing > > a "top" reveals that there isn't "an alien chewing into our stomach" > > anymore.. Tracker goes smoothly without doubt. > > > > Preferences panel shouldn't go split from the main interface though, > > IMO. > > Thanks for the feedback. I agree about the preferences disconnect. > Please file a RFE preferably on GNOME bugzilla. > > Rahul I also will add onto this thread, as someone that has continually had problems with beagle and have voiced my opinion on it. I find Tracker pretty usable and acceptable. I will whisper this silently here as to not wrinkle the feathers from other threads, "Tracker uses less cpu and binds IO even less if the filesystem is mounted noatime, ssssshhhhh". Actually tracker should open all the files noatime and that bug has been filed and agreed upon by the tracker team. My only real gripe right now is that it doesn't open my IM logs in pidgin, but as normal text files. Other than that it runs happily on my system and I almost don't even know it is there. I haven't poked at the code much, so I can't comment on that. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcepl at redhat.com Wed Aug 15 15:51:28 2007 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 15 Aug 2007 17:51:28 +0200 Subject: Meet the desktop team References: <1187141039.3199.21.camel@localhost.localdomain> Message-ID: On 2007-08-15, 01:23 GMT, Matthias Clasen wrote: > The first meeting is going to take place in the #fedora-meeting > irc channel on Freenode, Wednesday, 18:00-19:00 UTC (2pm-3pm EDT) > (see http://fedoraproject.org/wiki/Communicate#IRC) Do you have to? It's 20:00-21:00 CEST -- do you want to eliminate Europeans from participation? Mat?j From caillon at redhat.com Wed Aug 15 17:18:56 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 15 Aug 2007 13:18:56 -0400 Subject: Meet the desktop team In-Reply-To: References: <1187141039.3199.21.camel@localhost.localdomain> Message-ID: <46C33580.5050505@redhat.com> Matej Cepl wrote: > On 2007-08-15, 01:23 GMT, Matthias Clasen wrote: >> The first meeting is going to take place in the #fedora-meeting >> irc channel on Freenode, Wednesday, 18:00-19:00 UTC (2pm-3pm EDT) >> (see http://fedoraproject.org/wiki/Communicate#IRC) > > Do you have to? It's 20:00-21:00 CEST -- do you want to eliminate > Europeans from participation? Sigh. We don't do this and people complain. We do this, and people complain still. It's the only time some of us are free. If you actually want us to show up to our own talk, then this is the time. From caillon at redhat.com Wed Aug 15 17:39:07 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 15 Aug 2007 13:39:07 -0400 Subject: Meet the desktop team In-Reply-To: <46C33580.5050505@redhat.com> References: <1187141039.3199.21.camel@localhost.localdomain> <46C33580.5050505@redhat.com> Message-ID: <46C33A3B.40506@redhat.com> Christopher Aillon wrote: > Matej Cepl wrote: >> On 2007-08-15, 01:23 GMT, Matthias Clasen wrote: >>> The first meeting is going to take place in the #fedora-meeting >>> irc channel on Freenode, Wednesday, 18:00-19:00 UTC (2pm-3pm EDT) >>> (see http://fedoraproject.org/wiki/Communicate#IRC) >> >> Do you have to? It's 20:00-21:00 CEST -- do you want to eliminate >> Europeans from participation? > > Sigh. We don't do this and people complain. We do this, and people > complain still. > > It's the only time some of us are free. If you actually want us to show > up to our own talk, then this is the time. This sounded harsher than I really meant. We can discuss other times for future showings during the meeting, but it is hard to make meetings work for all time zones in general. This isn't the only Fedora meeting that is this late and there were other #fedora-meeting ones already scheduled before this one which prevented us from doing it earlier as well. Let's see what we can do to improve this during the meet, perhaps. From mclasen at redhat.com Wed Aug 15 19:56:23 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 15 Aug 2007 15:56:23 -0400 Subject: low-hanging fruit Message-ID: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> As discussed in the meeting, here is my personal "laundry list" of low-hanging fruit. Note that some of these are being worked on for F8 anyway. - enable nss-mdns by default - clean up emblems in nautilus - remove obsolete applets - reconsider default panel config (launchers) - unlock keyring on login - use xdg-user-dirs consistently - disable root login - get rid of xfs - get rid of pam_console - NM by default - PA by default - get rid of a bunch of services that we don't need on a live cd, like nfs/rpc/autofs - have a close look at the system-config tools we install - cleaned up artwork packaging And here are some larger things: - rethink installation and updates (see hughsie's recent work) - desktop background stuff: slideshows, channels, per-workspace - no lvm/raid in livecd installer - good xrandr 1.2 support - no root user - replace init system - new graphical boot - composited desktop by default - rethink user account handling: kiosk mode (?), guest accounts Matthias From blizzard at redhat.com Wed Aug 15 20:49:01 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 15 Aug 2007 16:49:01 -0400 Subject: Meet the desktop team In-Reply-To: <1187141039.3199.21.camel@localhost.localdomain> References: <1187141039.3199.21.camel@localhost.localdomain> Message-ID: <1187210941.2626.85.camel@localhost.localdomain> Meeting notes are up now: http://fedoraproject.org/wiki/SIGs/Desktop/Meeting-20070815 I also set up a Desktop "home page": http://fedoraproject.org/wiki/Desktop The idea being that we can keep a list of people, projects and updates on the page. Feel free to add your projects, goals and names to the page! --Chris From drago01 at gmail.com Wed Aug 15 21:20:06 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 15 Aug 2007 23:20:06 +0200 Subject: low-hanging fruit In-Reply-To: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: > > - no lvm/raid in livecd installer thats the only point where I disagree I don't see a reason to do this. what do we gain by doing this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajackson at redhat.com Wed Aug 15 21:32:03 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 15 Aug 2007 17:32:03 -0400 Subject: Meet the desktop team In-Reply-To: <1187210941.2626.85.camel@localhost.localdomain> References: <1187141039.3199.21.camel@localhost.localdomain> <1187210941.2626.85.camel@localhost.localdomain> Message-ID: <1187213523.2876.215.camel@localhost.localdomain> On Wed, 2007-08-15 at 16:49 -0400, Christopher Blizzard wrote: > Meeting notes are up now: > > http://fedoraproject.org/wiki/SIGs/Desktop/Meeting-20070815 > > I also set up a Desktop "home page": > > http://fedoraproject.org/wiki/Desktop > > The idea being that we can keep a list of people, projects and updates > on the page. Feel free to add your projects, goals and names to the > page! I promised to update the bootchart review request, and I did. Packages, for those who want them: http://ajax.fedorapeople.org/bootchart/ - ajax From ajackson at redhat.com Wed Aug 15 21:39:07 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 15 Aug 2007 17:39:07 -0400 Subject: low-hanging fruit In-Reply-To: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: <1187213947.2876.219.camel@localhost.localdomain> On Wed, 2007-08-15 at 15:56 -0400, Matthias Clasen wrote: > - get rid of xfs This is done, I think. notting fixed it so it doesn't even launch by default, even if it's installed. Should be safe to just drop from the package list. - ajax From caillon at redhat.com Wed Aug 15 21:42:39 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 15 Aug 2007 17:42:39 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: <46C3734F.8010005@redhat.com> dragoran wrote: > > > - no lvm/raid in livecd installer > > > thats the only point where I disagree I don't see a reason to do this. > what do we gain by doing this? Ask not what we gain but what we lose: confused users, and one less screen in the install since most people just click right through it. From skvidal at fedoraproject.org Wed Aug 15 21:45:31 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 15 Aug 2007 17:45:31 -0400 Subject: low-hanging fruit In-Reply-To: <46C3734F.8010005@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> Message-ID: <1187214331.13822.186.camel@cutter> On Wed, 2007-08-15 at 17:42 -0400, Christopher Aillon wrote: > dragoran wrote: > > > > > > - no lvm/raid in livecd installer > > > > > > thats the only point where I disagree I don't see a reason to do this. > > what do we gain by doing this? > > Ask not what we gain but what we lose: confused users, and one less > screen in the install since most people just click right through it. And we lose all of us who install from livecd and WANT lvm. I don't have any bootable media other than usb on most of my boxes and I like lvm :) it makes resizing spaces easier. -sv From katzj at redhat.com Wed Aug 15 21:52:30 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 15 Aug 2007 17:52:30 -0400 Subject: low-hanging fruit In-Reply-To: <46C3734F.8010005@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> Message-ID: <1187214750.6003.2.camel@localhost.localdomain> On Wed, 2007-08-15 at 17:42 -0400, Christopher Aillon wrote: > dragoran wrote: > > - no lvm/raid in livecd installer > > > > thats the only point where I disagree I don't see a reason to do this. > > what do we gain by doing this? > > Ask not what we gain but what we lose: confused users, and one less > screen in the install since most people just click right through it. ... except that unless they explicitly click on something, there isn't any screen for them to click on and be confused by. And hell, before they get there, they have to have clicked to do a custom partition layout. Jeremy From caillon at redhat.com Wed Aug 15 21:57:22 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 15 Aug 2007 17:57:22 -0400 Subject: low-hanging fruit In-Reply-To: <1187214331.13822.186.camel@cutter> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> Message-ID: <46C376C2.9010609@redhat.com> seth vidal wrote: > On Wed, 2007-08-15 at 17:42 -0400, Christopher Aillon wrote: >> dragoran wrote: >>> >>> - no lvm/raid in livecd installer >>> >>> >>> thats the only point where I disagree I don't see a reason to do this. >>> what do we gain by doing this? >> Ask not what we gain but what we lose: confused users, and one less >> screen in the install since most people just click right through it. > > And we lose all of us who install from livecd and WANT lvm. Which to be fair is probably a small percentage of users. But isn't one of the selling points of lvm that people can tweak their lvm partitions after the fact? Everyone that knows what it is and _WANTS_ to tweak it ought to be able to do this. From katzj at redhat.com Wed Aug 15 21:57:43 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 15 Aug 2007 17:57:43 -0400 Subject: low-hanging fruit In-Reply-To: <46C3734F.8010005@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> Message-ID: <1187215063.6003.5.camel@localhost.localdomain> On Wed, 2007-08-15 at 17:42 -0400, Christopher Aillon wrote: > dragoran wrote: > > - no lvm/raid in livecd installer > > > > thats the only point where I disagree I don't see a reason to do this. > > what do we gain by doing this? > > Ask not what we gain but what we lose: confused users, and one less > screen in the install since most people just click right through it. Oh, and one thing we lose is support for the very common "fake RAID" hardware which lots of people buy and use multiple disks in for desktops. Jeremy From mclasen at redhat.com Wed Aug 15 22:14:35 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 15 Aug 2007 18:14:35 -0400 Subject: pam, nm, pa (WAS: Meet the desktop team) In-Reply-To: References: <1187141039.3199.21.camel@localhost.localdomain> <1187210941.2626.85.camel@localhost.localdomain> Message-ID: <1187216075.4139.1.camel@localhost.localdomain> On Wed, 2007-08-15 at 23:50 +0200, Linus Walleij wrote: > On Wed, 15 Aug 2007, Christopher Blizzard wrote: > > > Meeting notes are up now > > Great! I only read those concrete things: > > # kill xfs > # kill pam console > # nm by default > # pa by default > > The first one I understand, not the three later ones, and they need > discussion on fedora-devel-list I believe, so could you elaborate or refer > to mail threads on the desktop list? Sorry for being too terse here. The three you ask about are explained in more detail in the wiki: http://fedoraproject.org/wiki/Releases/FeatureRemovePAMConsole http://fedoraproject.org/wiki/Releases/FeatureNetworkManager http://fedoraproject.org/wiki/Releases/FeaturePulseaudio All three are on the feature list for F8 and being worked on or already done. From mclasen at redhat.com Wed Aug 15 22:30:47 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 15 Aug 2007 18:30:47 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: <1187217052.4139.7.camel@localhost.localdomain> On Wed, 2007-08-15 at 23:20 +0200, dragoran wrote: > > > - no lvm/raid in livecd installer > > thats the only point where I disagree I don't see a reason to do > this. > what do we gain by doing this? Hmm, at least I got some reactions... keep in mind that what I posted was my personal laundry list, not some kind of official programme. Of course, everything that is in the installer got there because there is some use case for it. Maybe the point should be more "rethink the installer from the POV of streamlined desktop installation". Anyway, this is straying dangerously far from the subject of this thread... From kevin.kofler at chello.at Wed Aug 15 22:37:13 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 15 Aug 2007 22:37:13 +0000 (UTC) Subject: Meet the desktop team References: <1187141039.3199.21.camel@localhost.localdomain> Message-ID: Matthias Clasen redhat.com> writes: > We have put our ideas for second agenda item > up at http://www.fedoraproject.org/wiki/SIGs/Desktop IMHO, this page could really use a s/Desktop/GNOME/g. Kevin Kofler From dmalcolm at redhat.com Thu Aug 16 00:35:59 2007 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 15 Aug 2007 20:35:59 -0400 Subject: speech recognition for simple commands In-Reply-To: <469A8371.8050206@gmail.com> References: <4bcf41a00707070352u1f0753f5y6a81c285d72da484@mail.gmail.com> <1183809701.8979.235.camel@cookie.hadess.net> <1183891125.3437.2.camel@localhost.localdomain> <1183993732.4117.15.camel@cookie.hadess.net> <469A8371.8050206@gmail.com> Message-ID: <1187224560.8328.10.camel@cassandra.boston.redhat.com> On Mon, 2007-07-16 at 01:58 +0530, Rogue wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi All, > > Bastien Nocera wrote: > > On Sun, 2007-07-08 at 13:38 +0300, Marius Andreiana wrote: > >> On Sat, 2007-07-07 at 13:01 +0100, Bastien Nocera wrote: > >>> On Sat, 2007-07-07 at 13:52 +0300, Marius Andreiana wrote: > >>>> Hi, > >>>> > >>>> Are there any plans on including speech recognition in Fedora? (using > >>>> sphinx4 and at-spi maybe) > >>>> I'm looking only to simple commands translation (click, page up, close > >>>> window...), not full speech recognition. > >>> There's a Google SoC project about it: > >>> http://code.google.com/soc/2007/gnome/appinfo.html?csaid=4F64D394968BB092 > >> Looks good! > >> > >> Nickolay, let me know if you need help with testing or anything else > >> while you work on it, I'd love to see this implemented. > > > > Nickolay is the mentor, not the student working on the code. > > > > Raphael's already released code: > > http://raphaelnunes.wordpress.com/ > > > > Cheers > > > > I finally managed to get the code compiled on my system and in the > process built rpm files for both Sphinx2 and gnome-voice-control. I > tried out the applet and it for some reason did not work as expected. > May be I was expecting too much. > > I said "new" and it opened up tasks > I said "file" and it opened up Gedit. > > I understand that the project is still in its infancy, but I was > wondering what is the roadmap for this project? > > thanks, > Rogue > > p.s.: If someone is interested in the RPM files, i can host them at some > location, but note that I am new to the whole RPM thingy, so I may not > have set up the dependencies right! I've also had a go at packaging them; specfiles and SRPMs can be seen here: http://people.redhat.com/dmalcolm/gnome-voice-control/ The spec files aren't ready to go pass the review process yet, though. Hope this helps Dave From jon.nettleton at gmail.com Thu Aug 16 04:31:10 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Thu, 16 Aug 2007 00:31:10 -0400 Subject: low-hanging fruit In-Reply-To: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: On 8/15/07, Matthias Clasen wrote: > > As discussed in the meeting, here is my personal > "laundry list" of low-hanging fruit. Note that some of > these are being worked on for F8 anyway. > > - enable nss-mdns by default > - clean up emblems in nautilus > - remove obsolete applets > - reconsider default panel config (launchers) > - unlock keyring on login This should be included in gnome 2.20 with the new gnome-keyring. It includes a pam module to do this. If it doesn't then I can finish hacking pam_keyring to do what we want. - use xdg-user-dirs consistently > - disable root login I don't know why. I think the goal is ot make security seamless enough that people don't feel the "need" to log in as root. - get rid of xfs > - get rid of pam_console In the long run YES! This is probably not happening for Fedora 8. Should we instead use the UGROUPS property to allow users to have administrative gui privileges in the short term. Could win back some popularity among reviewers. Yes I know how awful that sounds, but it is a fact of life. - NM by default Would love to see this. Don't know if we can make it > - PA by default > - get rid of a bunch of services that we don't need on a > live cd, like nfs/rpc/autofs > - have a close look at the system-config tools we install > - cleaned up artwork packaging > > And here are some larger things: > > - rethink installation and updates (see hughsie's > recent work) > - desktop background stuff: > slideshows, channels, per-workspace > - no lvm/raid in livecd installer > - good xrandr 1.2 support > - no root user > - replace init system I don't know if the init system needs to be replaced or just rethought. I have been hacking on this on and off for the past 3-4 days and my conclusion is that the perception of the boot process is more important than what actually happens. The first 17 seconds of boot is tied to hardware and display initialization. From there everything leads up to what "needs" to be running when a user logs in. I am working on a proper write up > - new graphical boot Since we have to start X eventually I don't see the big problem with rhgb. I am trying to finish up my work getting rhgb to start in the gdm init scripts. This allows rhgb and gdm to share an initial xserver and give a smoother boot process. - composited desktop by default Would love to see this. For my own personal use I have started hacking more gnomish features into xfwm4. Basically a new config gui and gconf functionality for storing settings. I know most people could care less but I think it will give a good 2d composited desktop option based on some solid window manager work by the XFCE guys. - rethink user account handling: > kiosk mode (?), guest accounts I think our problem has become looking for a magic bullet solution for everything, and neglecting good ideas waiting on that idea. NetworkManager is the future of networking for linux but we have been neglecting other solutions for years waiting on it. Composited desktops, init-system, and graphical booting are going to be the new ones. Perhaps it is time to start planning in smaller steps. It is great to have the grand vision but we tend to fall behind waiting for that to happen. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicu_fedora at nicubunu.ro Thu Aug 16 06:06:49 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 16 Aug 2007 09:06:49 +0300 Subject: low-hanging fruit In-Reply-To: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: <46C3E979.20409@nicubunu.ro> Matthias Clasen wrote: > > - reconsider default panel config (launchers) This is something I think is badly needed, for quite some time I wanted to talk about this but was not bold enough to bring the topic out so far. I think is about the time for the OpenOffice.org icons to go away from the default panel, they were useful some years ago to inform people Fedora has a capable Office Suite, but by now everybody know and expect this and an office suite is boring. I think those launchers would be better replaced by something people like: multimedia, at least a launcher for Rhythmbox and maybe something people really use (usage stats gathered from Mugshot, but this would suggest a launcher for the terminal as very desired). -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From drago01 at gmail.com Thu Aug 16 07:08:42 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 16 Aug 2007 09:08:42 +0200 Subject: low-hanging fruit In-Reply-To: <46C3734F.8010005@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> Message-ID: <46C3F7FA.8020506@gmail.com> Christopher Aillon wrote: > dragoran wrote: >> >> >> - no lvm/raid in livecd installer >> >> >> thats the only point where I disagree I don't see a reason to do this. >> what do we gain by doing this? > > Ask not what we gain but what we lose: confused users, and one less > screen in the install since most people just click right through it. > user who don't care just click next and be done with it.. others select "advanced options" and tweak ther partitioning (even many desktop users do this) and I doubt that this confuses users. From gmureddu at prodigy.net.mx Thu Aug 16 07:10:09 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Thu, 16 Aug 2007 03:10:09 -0400 Subject: low-hanging fruit In-Reply-To: <1187214750.6003.2.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214750.6003.2.camel@localhost.localdomain> Message-ID: <46C3F851.90907@prodigy.net.mx> Jeremy Katz escribi?: > On Wed, 2007-08-15 at 17:42 -0400, Christopher Aillon wrote: > >> dragoran wrote: >> >>> - no lvm/raid in livecd installer >>> >>> thats the only point where I disagree I don't see a reason to do this. >>> what do we gain by doing this? >>> >> Ask not what we gain but what we lose: confused users, and one less >> screen in the install since most people just click right through it. >> > > ... except that unless they explicitly click on something, there isn't > any screen for them to click on and be confused by. And hell, before > they get there, they have to have clicked to do a custom partition > layout. > > Jeremy > > Why not have a partition layout similar to "old RH 6.2-7.3" and be done with LVM on default. Just this time instead of three partitions have four default partitions, one for /home so it would be easier to wipe clean the system and upgrade distros without destroying personal data? Or better yet (for LVM lovers) do THAT with LVM enabled, if you will, or use LVM only for / and /home, but for goodness sake, HAVE a /home default mount point and to be another partition! From gmureddu at prodigy.net.mx Thu Aug 16 07:15:03 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Thu, 16 Aug 2007 03:15:03 -0400 Subject: low-hanging fruit In-Reply-To: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: <46C3F977.5060305@prodigy.net.mx> Matthias Clasen escribi?: > - no root user > Oh please no! (fine fort the LiveCD, but absolutely NOT for the installed version!) I recently HAD to enable the root account in a *buntu system as trying to do some batch stuff with BASH with for-in loops and stuff is FUTILE without a *proper* root account (yes, I tend to use quite a bit for-in loops for repetitive commands in a single command line). Seamless security is fine with me, but a *proper* account will still be needed for those where should anything go wrong and you require to do emergency maintenance. From nphilipp at redhat.com Thu Aug 16 08:17:21 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 16 Aug 2007 10:17:21 +0200 Subject: low-hanging fruit In-Reply-To: <46C376C2.9010609@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> Message-ID: <1187252241.28935.6.camel@wombat.tiptoe.de> On Wed, 2007-08-15 at 17:57 -0400, Christopher Aillon wrote: > seth vidal wrote: > > On Wed, 2007-08-15 at 17:42 -0400, Christopher Aillon wrote: > >> dragoran wrote: > >>> > >>> - no lvm/raid in livecd installer > >>> > >>> > >>> thats the only point where I disagree I don't see a reason to do this. > >>> what do we gain by doing this? > >> Ask not what we gain but what we lose: confused users, and one less > >> screen in the install since most people just click right through it. > > > > And we lose all of us who install from livecd and WANT lvm. > > > Which to be fair is probably a small percentage of users. But isn't one > of the selling points of lvm that people can tweak their lvm partitions > after the fact? Everyone that knows what it is and _WANTS_ to tweak it > ought to be able to do this. "... their lvm partitions ..." are the keywords here. If you don't install onto LVM logical volumes (on physical volumes, a.k.a. partitions) when installing you basically have to backup your data, scrap your partitions and restore. Ergo, people who want to use LVM won't install from a live CD that doesn't offer this option. As a side point, everybody should be using LVM. Directly operating on partitions is so 1980. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From sundaram at fedoraproject.org Thu Aug 16 08:44:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Aug 2007 14:14:24 +0530 Subject: low-hanging fruit In-Reply-To: <46C3F977.5060305@prodigy.net.mx> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> Message-ID: <46C40E68.4000509@fedoraproject.org> Gian Paolo Mureddu wrote: > Matthias Clasen escribi?: >> - no root user >> > > Oh please no! (fine fort the LiveCD, but absolutely NOT for the > installed version!) I recently HAD to enable the root account in a > *buntu system as trying to do some batch stuff with BASH with for-in > loops and stuff is FUTILE without a *proper* root account (yes, I tend > to use quite a bit for-in loops for repetitive commands in a single > command line). Seamless security is fine with me, but a *proper* account > will still be needed for those where should anything go wrong and you > require to do emergency maintenance. # sudo su - Rahul From sundaram at fedoraproject.org Thu Aug 16 08:56:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Aug 2007 14:26:38 +0530 Subject: low-hanging fruit In-Reply-To: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: <46C41146.6060407@fedoraproject.org> Matthias Clasen wrote: > - use xdg-user-dirs consistently What does this require? > - disable root login Anything more than sudo and GDM access? > - cleaned up artwork packaging might want to rename the package fedora-artwork now. > - no lvm/raid in livecd installer As others have pointed out LVM can be quite useful for desktop users too. > - no root user > - replace init system Not sure what these two involve. Rahul From sundaram at fedoraproject.org Thu Aug 16 08:58:26 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Aug 2007 14:28:26 +0530 Subject: Meet the desktop team In-Reply-To: References: <1187141039.3199.21.camel@localhost.localdomain> Message-ID: <46C411B2.4080706@fedoraproject.org> Kevin Kofler wrote: > Matthias Clasen redhat.com> writes: >> We have put our ideas for second agenda item >> up at http://www.fedoraproject.org/wiki/SIGs/Desktop > > IMHO, this page could really use a s/Desktop/GNOME/g. I would prefer the Desktop SIG takes care of more than just a single desktop environment and probably should include KDE folks too. Rahul From sundaram at fedoraproject.org Thu Aug 16 08:59:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Aug 2007 14:29:09 +0530 Subject: Meet the desktop team In-Reply-To: <1187210941.2626.85.camel@localhost.localdomain> References: <1187141039.3199.21.camel@localhost.localdomain> <1187210941.2626.85.camel@localhost.localdomain> Message-ID: <46C411DD.3000104@fedoraproject.org> Christopher Blizzard wrote: > Meeting notes are up now: > > http://fedoraproject.org/wiki/SIGs/Desktop/Meeting-20070815 Can someone post the raw IRC logs too? Rahul From drago01 at gmail.com Thu Aug 16 09:01:17 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 16 Aug 2007 11:01:17 +0200 Subject: low-hanging fruit In-Reply-To: <46C41146.6060407@fedoraproject.org> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C41146.6060407@fedoraproject.org> Message-ID: <46C4125D.5060507@gmail.com> Rahul Sundaram wrote: > Matthias Clasen wrote: > >> - use xdg-user-dirs consistently > > What does this require? > patch apps that use hardcoded dirs to use xdg-user-dirs instead >> - disable root login > > Anything more than sudo and GDM access? > policykit integration >> - no lvm/raid in livecd installer > > As others have pointed out LVM can be quite useful for desktop users too. > same for raid (and dmraid) From dwinship at redhat.com Thu Aug 16 13:14:01 2007 From: dwinship at redhat.com (Dan Winship) Date: Thu, 16 Aug 2007 09:14:01 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: <46C44D99.7060202@redhat.com> Jon Nettleton wrote: > On 8/15/07, *Matthias Clasen* - unlock keyring on login > > This should be included in gnome 2.20 with the new gnome-keyring. > It includes a pam module to do this. If it doesn't then I can finish > hacking pam_keyring to do what we want. I can log into Fedora on my Thinkpad by just swiping my finger on the fingerprint reader. Ideally that would unlock my keyring too, which is impossible with the combination of pam_thinkfinger and pam_keyring. -- Dan From mclasen at redhat.com Thu Aug 16 13:41:01 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 16 Aug 2007 09:41:01 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: <1187271662.3296.0.camel@dhcp83-186.boston.redhat.com> On Thu, 2007-08-16 at 00:31 -0400, Jon Nettleton wrote: > > > This should be included in gnome 2.20 with the new gnome-keyring. > It includes a pam module to do this. If it doesn't then I can finish > hacking > pam_keyring to do what we want. Yeah, we ship this in the gnome-keyring-pam package, and it is included in the gdm and gnome-screensaver pam configurations. From mclasen at redhat.com Thu Aug 16 13:43:15 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 16 Aug 2007 09:43:15 -0400 Subject: low-hanging fruit In-Reply-To: <46C44D99.7060202@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C44D99.7060202@redhat.com> Message-ID: <1187271795.3296.3.camel@dhcp83-186.boston.redhat.com> On Thu, 2007-08-16 at 09:14 -0400, Dan Winship wrote: > Jon Nettleton wrote: > > On 8/15/07, *Matthias Clasen* > - unlock keyring on login > > > > This should be included in gnome 2.20 with the new gnome-keyring. > > It includes a pam module to do this. If it doesn't then I can finish > > hacking pam_keyring to do what we want. > > I can log into Fedora on my Thinkpad by just swiping my finger on the > fingerprint reader. Ideally that would unlock my keyring too, which is > impossible with the combination of pam_thinkfinger and pam_keyring. Probably worthwhile to point that concern out on the feature page that Bastien set up for pam_thinkfinger as an F9 feature, http://fedoraproject.org/wiki/Releases/FeatureThinkfinger From dcbw at redhat.com Thu Aug 16 15:58:36 2007 From: dcbw at redhat.com (Dan Williams) Date: Thu, 16 Aug 2007 11:58:36 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: <1187279916.27199.30.camel@xo-13-A4-25.localdomain> On Thu, 2007-08-16 at 00:31 -0400, Jon Nettleton wrote: > On 8/15/07, Matthias Clasen wrote: > As discussed in the meeting, here is my personal > "laundry list" of low-hanging fruit. Note that some of > these are being worked on for F8 anyway. > > - enable nss-mdns by default > - clean up emblems in nautilus > - remove obsolete applets > - reconsider default panel config (launchers) > - unlock keyring on login > > This should be included in gnome 2.20 with the new gnome-keyring. > It includes a pam module to do this. If it doesn't then I can finish > hacking > pam_keyring to do what we want. > > > - use xdg-user-dirs consistently > - disable root login > > I don't know why. I think the goal is ot make security seamless > enough > that people don't feel the "need" to log in as root. > > > - get rid of xfs > - get rid of pam_console > > In the long run YES! This is probably not happening for Fedora 8. > Should we instead use the UGROUPS property to allow users to > have administrative gui privileges in the short term. Could win > back some popularity among reviewers. Yes I know how awful > that sounds, but it is a fact of life. > > > - NM by default > > Would love to see this. Don't know if we can make it We're trying :) > - PA by default > - get rid of a bunch of services that we don't need on a > live cd, like nfs/rpc/autofs > - have a close look at the system-config tools we install > - cleaned up artwork packaging > > And here are some larger things: > > - rethink installation and updates (see hughsie's > recent work) > - desktop background stuff: > slideshows, channels, per-workspace > - no lvm/raid in livecd installer > - good xrandr 1.2 support > - no root user > - replace init system > > I don't know if the init system needs to be replaced or just > rethought. > I have been hacking on this on and off for the past 3-4 days and my > conclusion is that the perception of the boot process is more > important > than what actually happens. The first 17 seconds of boot is tied to > hardware and display initialization. From there everything leads up > to what > "needs" to be running when a user logs in. I am working on a proper > write up > > - new graphical boot > > Since we have to start X eventually I don't see the big problem with > rhgb. > I am trying to finish up my work getting rhgb to start in the gdm init > scripts. > This allows rhgb and gdm to share an initial xserver and give a > smoother > boot process. > > > - composited desktop by default > > Would love to see this. For my own personal use I have started > hacking > more gnomish features into xfwm4. Basically a new config gui and > gconf > functionality for storing settings. I know most people could care > less but > I think it will give a good 2d composited desktop option based on some > solid window manager work by the XFCE guys. > > > - rethink user account handling: > kiosk mode (?), guest accounts > > > I think our problem has become looking for a magic bullet solution for > everything, > and neglecting good ideas waiting on that idea. NetworkManager is the > future of > networking for linux but we have been neglecting other solutions for > years waiting > on it. Composited desktops, init-system, and graphical booting are > going to be > the new ones. Perhaps it is time to start planning in smaller steps. > It is great to > have the grand vision but we tend to fall behind waiting for that to > happen. > > Jon > > > > > > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list From jrb at redhat.com Thu Aug 16 16:04:47 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Thu, 16 Aug 2007 12:04:47 -0400 Subject: low-hanging fruit In-Reply-To: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: <1187280287.2718.17.camel@localhost.localdomain> On Wed, 2007-08-15 at 15:56 -0400, Matthias Clasen wrote: > As discussed in the meeting, here is my personal > "laundry list" of low-hanging fruit. Note that some of > these are being worked on for F8 anyway. > > - enable nss-mdns by default > - clean up emblems in nautilus > - remove obsolete applets > - reconsider default panel config (launchers) > - unlock keyring on login > - use xdg-user-dirs consistently > - disable root login > - get rid of xfs > - get rid of pam_console > - NM by default > - PA by default > - get rid of a bunch of services that we don't need on a > live cd, like nfs/rpc/autofs > - have a close look at the system-config tools we install > - cleaned up artwork packaging Some quick thoughts: Might be less low-hanging fruit, but give firstboot a quick look: - user icon as part of new user creation - good defaults for firewall/selinux/sound cards Hook up the mugshot.org/applications database to figure out a mime-type->package tool Thanks, -Jonathan From katzj at redhat.com Thu Aug 16 17:22:54 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Aug 2007 13:22:54 -0400 Subject: low-hanging fruit In-Reply-To: <1187280287.2718.17.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> Message-ID: <1187284974.17169.4.camel@localhost.localdomain> On Thu, 2007-08-16 at 12:04 -0400, Jonathan Blandford wrote: > Might be less low-hanging fruit, but give firstboot a quick look: > - user icon as part of new user creation This should be pretty quick and simple to do; add a button to pop up the file selector, then copy the file. /usr/share/firstboot/modules/create_user.py for anyone interested in taking a look > - good defaults for firewall/selinux/sound cards Let's go for broke and just try to get the firstboot modules for these removed altogether like we've discussed from time to time. The defaults here are already pretty sane, imho. Okay, maybe we have to leave firewall as we don't have the good way of doing "enable service ==> poke hole" yet. But there's no reason that soundcard and selinux can't be nuked from orbit. Jeremy From jrb at redhat.com Thu Aug 16 18:04:37 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Thu, 16 Aug 2007 14:04:37 -0400 Subject: low-hanging fruit In-Reply-To: <1187284974.17169.4.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <1187284974.17169.4.camel@localhost.localdomain> Message-ID: <1187287477.2718.31.camel@localhost.localdomain> On Thu, 2007-08-16 at 13:22 -0400, Jeremy Katz wrote: > > - good defaults for firewall/selinux/sound cards > > Let's go for broke and just try to get the firstboot modules for these > removed altogether like we've discussed from time to time. The defaults > here are already pretty sane, imho. Okay, maybe we have to leave > firewall as we don't have the good way of doing "enable service ==> poke > hole" yet. But there's no reason that soundcard and selinux can't be > nuked from orbit. Sounds really good to me. Can't we nuke firewall too? You can run the firewall tool afterward if needed. Thanks, -Jonathan From katzj at redhat.com Thu Aug 16 18:10:35 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Aug 2007 14:10:35 -0400 Subject: low-hanging fruit In-Reply-To: <1187287477.2718.31.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <1187284974.17169.4.camel@localhost.localdomain> <1187287477.2718.31.camel@localhost.localdomain> Message-ID: <1187287835.17169.13.camel@localhost.localdomain> On Thu, 2007-08-16 at 14:04 -0400, Jonathan Blandford wrote: > On Thu, 2007-08-16 at 13:22 -0400, Jeremy Katz wrote: > > > - good defaults for firewall/selinux/sound cards > > > > Let's go for broke and just try to get the firstboot modules for these > > removed altogether like we've discussed from time to time. The defaults > > here are already pretty sane, imho. Okay, maybe we have to leave > > firewall as we don't have the good way of doing "enable service ==> poke > > hole" yet. But there's no reason that soundcard and selinux can't be > > nuked from orbit. > > Sounds really good to me. Can't we nuke firewall too? You can run the > firewall tool afterward if needed. I'm not against it. The complaint will be that people will just get failures and not have anything to show them why. Maybe we can get the quick change into the default firewall rules so that they'll log failures so that it's not at least entirely silent Jeremy From jkeating at redhat.com Thu Aug 16 18:17:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Aug 2007 14:17:30 -0400 Subject: low-hanging fruit In-Reply-To: <1187287835.17169.13.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <1187284974.17169.4.camel@localhost.localdomain> <1187287477.2718.31.camel@localhost.localdomain> <1187287835.17169.13.camel@localhost.localdomain> Message-ID: <20070816141730.3356f3c3@mentok.boston.redhat.com> On Thu, 16 Aug 2007 14:10:35 -0400 Jeremy Katz wrote: > I'm not against it. The complaint will be that people will just get > failures and not have anything to show them why. Maybe we can get the > quick change into the default firewall rules so that they'll log > failures so that it's not at least entirely silent +10, that's the most annoying thing to me about our default rules. It's so silent. If we're afraid of it drowning out /var/log/messages we could send it to a firewall log file. But I'm all for dropping these from Firstboot and going with our defaults. Anybody for firewall2allow? (: -- 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 jon.nettleton at gmail.com Thu Aug 16 19:26:11 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Thu, 16 Aug 2007 15:26:11 -0400 Subject: low-hanging fruit In-Reply-To: <46C44D99.7060202@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C44D99.7060202@redhat.com> Message-ID: On 8/16/07, Dan Winship wrote: > > Jon Nettleton wrote: > > On 8/15/07, *Matthias Clasen* > - unlock keyring on login > > > > This should be included in gnome 2.20 with the new gnome-keyring. > > It includes a pam module to do this. If it doesn't then I can finish > > hacking pam_keyring to do what we want. > > I can log into Fedora on my Thinkpad by just swiping my finger on the > fingerprint reader. Ideally that would unlock my keyring too, which is > impossible with the combination of pam_thinkfinger and pam_keyring. We addressed this back with pam_bioapi, and I think it only partially got implemented. The idea was to embed the passphrase into the bir of the user. Then have the pam module populate AUTH_TOK with the passphrase and pass it along to subsequent pam_modules in the stack. I don't want my finger cut off to get to my data so I steer clear. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidz at redhat.com Thu Aug 16 21:07:53 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 16 Aug 2007 17:07:53 -0400 Subject: low-hanging fruit In-Reply-To: <1187214750.6003.2.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214750.6003.2.camel@localhost.localdomain> Message-ID: <1187298473.3788.68.camel@oneill.fubar.dk> On Wed, 2007-08-15 at 17:52 -0400, Jeremy Katz wrote: > On Wed, 2007-08-15 at 17:42 -0400, Christopher Aillon wrote: > > dragoran wrote: > > > - no lvm/raid in livecd installer > > > > > > thats the only point where I disagree I don't see a reason to do this. > > > what do we gain by doing this? > > > > Ask not what we gain but what we lose: confused users, and one less > > screen in the install since most people just click right through it. > > ... except that unless they explicitly click on something, there isn't > any screen for them to click on and be confused by. And hell, before > they get there, they have to have clicked to do a custom partition > layout. ... and the user goes "What's a custom partition layout?" and clicks the button because he finds it "cool" and "interesting". Really, partitioning needs to be as simple as this slider based thing +-----------------------------------------------+ | HOW MUCH FEDORA CAN YOU HANDLE? | | | | Disk: [Internal FUJITSU MHV2120B SATA Disk|V] | <-- hide this | | combobox if | ^ | there is only | + Fedora | Other OS's + | one disk | V | | | | [ ] Use entire disk for Fedora | | | | [Cancel] [Next] | +-----------------------------------------------+ No questions about boot loaders (just always add all the other OS'es to grub.conf). No mention of RAID or LVM (this doesn't mean we can't use LVM for what we install to (though I'm always annoyed by this as a developer); I just don't want to see the question asked in the UI). What I like really to see is anaconda having the ability to do headless installs and we can simply write a nice and simple GTK+. The kickstart file would include directives such as "use disk /dev/sda; resize all other OS's so what we install takes up 40% of the disk". We'd bother the user with other types of questions (like the ones in firstboot + more including face/background choice) while we actually do the install. Jeremy, any chance we can change anaconda such that we can slap a simpler UI, decoupled from the actual mechanism, on top of it? Thanks. David From davidz at redhat.com Thu Aug 16 21:27:17 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 16 Aug 2007 17:27:17 -0400 Subject: low-hanging fruit In-Reply-To: <1187252241.28935.6.camel@wombat.tiptoe.de> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> Message-ID: <1187299637.3788.73.camel@oneill.fubar.dk> On Thu, 2007-08-16 at 10:17 +0200, Nils Philippsen wrote: > As a side point, everybody should be using LVM. Directly operating on > partitions is so 1980. Speaking as a developer, you can boot a kernel from your home directory if /home is on LVM. Hence, LVM is definitely something to avoid for more developer oriented flavors on Fedora. David From davidz at redhat.com Thu Aug 16 21:33:18 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 16 Aug 2007 17:33:18 -0400 Subject: low-hanging fruit In-Reply-To: <46C3E979.20409@nicubunu.ro> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> Message-ID: <1187299998.3788.79.camel@oneill.fubar.dk> On Thu, 2007-08-16 at 09:06 +0300, Nicu Buculei wrote: > Matthias Clasen wrote: > > > > - reconsider default panel config (launchers) > > This is something I think is badly needed, for quite some time I wanted > to talk about this but was not bold enough to bring the topic out so far. > I think is about the time for the OpenOffice.org icons to go away from > the default panel, they were useful some years ago to inform people > Fedora has a capable Office Suite, but by now everybody know and expect > this and an office suite is boring. > I think those launchers would be better replaced by something people > like: multimedia, at least a launcher for Rhythmbox and maybe something > people really use (usage stats gathered from Mugshot, but this would > suggest a launcher for the terminal as very desired). +1 for doing this; in the same breath we should depart from having the generic web browser launcher in the panel and instead just add the Firefox launcher or whatever default browser we ship [1]. Definitely something we can and should do in this release. David [1] : IIRC the reason for the generic launcher is that the program it launches actually picks the browser from your choice made in the "Preferred Applications" caplet. Ie. the thinking, or so I was explained, is that if you change your browser in "Preferred Applications", the launcher will respect that choice. However, I think the price of having that eyesore is too high; users who know how to go into "Preferred Applications" are most likely more than capable of removing the Firefox launcher from their panel. From davidz at redhat.com Thu Aug 16 21:36:37 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 16 Aug 2007 17:36:37 -0400 Subject: low-hanging fruit In-Reply-To: <1187299637.3788.73.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> Message-ID: <1187300197.3788.81.camel@oneill.fubar.dk> On Thu, 2007-08-16 at 17:27 -0400, David Zeuthen wrote: > On Thu, 2007-08-16 at 10:17 +0200, Nils Philippsen wrote: > > As a side point, everybody should be using LVM. Directly operating on > > partitions is so 1980. > > Speaking as a developer, you can boot a kernel from your home directory ^^^^ I meant can't of course. Sorry. > if /home is on LVM. Hence, LVM is definitely something to avoid for more > developer oriented flavors on Fedora. > > David > > From davej at redhat.com Thu Aug 16 21:50:47 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 16 Aug 2007 17:50:47 -0400 Subject: low-hanging fruit In-Reply-To: <1187299637.3788.73.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> Message-ID: <20070816215047.GA25895@redhat.com> On Thu, Aug 16, 2007 at 05:27:17PM -0400, David Zeuthen wrote: > > On Thu, 2007-08-16 at 10:17 +0200, Nils Philippsen wrote: > > As a side point, everybody should be using LVM. Directly operating on > > partitions is so 1980. > > Speaking as a developer, you can't boot a kernel from your home directory > if /home is on LVM. wtf, why would you do that? Given you need to install modules outside of your homedir in /lib anyway, is putting the kernel into /boot so hard? Dave -- http://www.codemonkey.org.uk From drago01 at gmail.com Thu Aug 16 21:41:17 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 16 Aug 2007 23:41:17 +0200 Subject: low-hanging fruit In-Reply-To: <1187298473.3788.68.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214750.6003.2.camel@localhost.localdomain> <1187298473.3788.68.camel@oneill.fubar.dk> Message-ID: On 8/16/07, David Zeuthen wrote: > > > On Wed, 2007-08-15 at 17:52 -0400, Jeremy Katz wrote: > > On Wed, 2007-08-15 at 17:42 -0400, Christopher Aillon wrote: > > > dragoran wrote: > > > > - no lvm/raid in livecd installer > > > > > > > > thats the only point where I disagree I don't see a reason to do > this. > > > > what do we gain by doing this? > > > > > > Ask not what we gain but what we lose: confused users, and one less > > > screen in the install since most people just click right through it. > > > > ... except that unless they explicitly click on something, there isn't > > any screen for them to click on and be confused by. And hell, before > > they get there, they have to have clicked to do a custom partition > > layout. > > ... and the user goes "What's a custom partition layout?" and clicks the > button because he finds it "cool" and "interesting". Really, > partitioning needs to be as simple as this slider based thing > > +-----------------------------------------------+ > | HOW MUCH FEDORA CAN YOU HANDLE? | > | | > | Disk: [Internal FUJITSU MHV2120B SATA Disk|V] | <-- hide this > | | combobox if > | ^ | there is only > | + Fedora | Other OS's + | one disk > | V | > | | > | [ ] Use entire disk for Fedora | > | | > | [Cancel] [Next] | > +-----------------------------------------------+ > > No questions about boot loaders (just always add all the other OS'es to > grub.conf). No mention of RAID or LVM (this doesn't mean we can't use > LVM for what we install to (though I'm always annoyed by this as a > developer); I just don't want to see the question asked in the UI). but whats wrong with raid? and as jeremy already said dmraid? "this is a desktop install raid is not supported anymore" does not make sense to me . what about only adding it when there is more than 1 disk or when a dmraid device is found? -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidz at redhat.com Thu Aug 16 21:50:19 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 16 Aug 2007 17:50:19 -0400 Subject: low-hanging fruit In-Reply-To: <20070816215047.GA25895@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <20070816215047.GA25895@redhat.com> Message-ID: <1187301019.3788.84.camel@oneill.fubar.dk> On Thu, 2007-08-16 at 17:50 -0400, Dave Jones wrote: > On Thu, Aug 16, 2007 at 05:27:17PM -0400, David Zeuthen wrote: > > > > On Thu, 2007-08-16 at 10:17 +0200, Nils Philippsen wrote: > > > As a side point, everybody should be using LVM. Directly operating on > > > partitions is so 1980. > > > > Speaking as a developer, you can't boot a kernel from your home directory > > if /home is on LVM. > > wtf, why would you do that? Given you need to install modules > outside of your homedir in /lib anyway, is putting the kernel > into /boot so hard? I just build everything in (except the bits I'm hacking on); makes it much faster to compile too. To each their own I guess. David From bnocera at redhat.com Thu Aug 16 21:53:54 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 16 Aug 2007 22:53:54 +0100 Subject: PA by default Message-ID: <1187301234.26239.30.camel@cookie.hadess.net> Heya, Before Fedora 8, is there a plan to fix a few regressions or integration issue with PA? From: https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01196.html > You also have to make sure that some GConf keys are set up properly: > > /system/gstreamer/0.10/default/audiosrc -> pulsesrc > /system/gstreamer/0.10/default/audiosink -> pulsesink (or autoaudiosink) > /system/gstreamer/0.10/default/chataudiosink -> pulsesink (or autoaudiosink) > /system/gstreamer/0.10/default/musicaudiosink -> pulsesink (or autoaudiosink) This means that the "Devices" part of the Sound Preferences in GNOME is pretty useless. I guess there's a PA specific way of changing the default input and output, but you lose integration with the desktop. This will also probably break the device selection that the volume applet uses (it uses the same as the default sound events device, iirc). I'm also thinking of applications' volume setup. At least Totem and Rhythmbox have the concept of "system volume" (which is per device, and they don't touch), and the "application volume" (which they do). Here, we're adding the "PA volume". How do we plan on handling that? Cheers From mcepl at redhat.com Thu Aug 16 21:33:50 2007 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 16 Aug 2007 23:33:50 +0200 Subject: Meet the desktop team References: <1187141039.3199.21.camel@localhost.localdomain> <46C33580.5050505@redhat.com> <46C33A3B.40506@redhat.com> Message-ID: ["Followup-To:" header set to gmane.linux.redhat.fedora.desktop.] On 2007-08-15, 17:39 GMT, Christopher Aillon wrote: > This sounded harsher than I really meant. We can discuss other > times for future showings during the meeting, but it is hard to > make meetings work for all time zones in general. This isn't > the only Fedora meeting that is this late and there were other > #fedora-meeting ones already scheduled before this one which > prevented us from doing it earlier as well. Let's see what we > can do to improve this during the meet, perhaps. Sure, if I was just a volunteer (and not-married ;-)) I would probably prefer 20-21. Oh well, my bad. I just thought that the time of desktop team meetings (17:00 CEST, 11 EST) covers most of possible participants (I am really sorry for folks in India and Australia, and guys on the West Coast have to get up early -- but they do anyway). Matej From jspaleta at gmail.com Thu Aug 16 21:55:37 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 16 Aug 2007 13:55:37 -0800 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214750.6003.2.camel@localhost.localdomain> <1187298473.3788.68.camel@oneill.fubar.dk> Message-ID: <604aa7910708161455na3a3655s81016e949a57c66b@mail.gmail.com> On 8/16/07, dragoran wrote: > what about only adding it when there is more than 1 disk or when a dmraid > device is found? Multiple disk and dmraid detection pretty much guarantees I'd never see it on the desktop machines I interact with. -jef From davidz at redhat.com Thu Aug 16 21:53:17 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 16 Aug 2007 17:53:17 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214750.6003.2.camel@localhost.localdomain> <1187298473.3788.68.camel@oneill.fubar.dk> Message-ID: <1187301197.3788.88.camel@oneill.fubar.dk> On Thu, 2007-08-16 at 23:41 +0200, dragoran wrote: > but whats wrong with raid? and as jeremy already said dmraid? > "this is a desktop install raid is not supported anymore" does not > make sense to me . > what about only adding it when there is more than 1 disk or when a > dmraid device is found? What makes you think we wouldn't handle dmraid with such a setup? The combined disk would just appear in the dropdown menu. David From davidz at redhat.com Thu Aug 16 21:54:18 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 16 Aug 2007 17:54:18 -0400 Subject: low-hanging fruit In-Reply-To: <1187301019.3788.84.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <20070816215047.GA25895@redhat.com> <1187301019.3788.84.camel@oneill.fubar.dk> Message-ID: <1187301258.3788.90.camel@oneill.fubar.dk> On Thu, 2007-08-16 at 17:50 -0400, David Zeuthen wrote: > On Thu, 2007-08-16 at 17:50 -0400, Dave Jones wrote: > > On Thu, Aug 16, 2007 at 05:27:17PM -0400, David Zeuthen wrote: > > > > > > On Thu, 2007-08-16 at 10:17 +0200, Nils Philippsen wrote: > > > > As a side point, everybody should be using LVM. Directly operating on > > > > partitions is so 1980. > > > > > > Speaking as a developer, you can't boot a kernel from your home directory > > > if /home is on LVM. > > > > wtf, why would you do that? Given you need to install modules > > outside of your homedir in /lib anyway, is putting the kernel > > into /boot so hard? > > I just build everything in (except the bits I'm hacking on); makes it > much faster to compile too. To each their own I guess. Ugh, replying to myself again. s/everything/everything I need for the particular box I'm using/. David From davej at redhat.com Thu Aug 16 22:22:10 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 16 Aug 2007 18:22:10 -0400 Subject: low-hanging fruit In-Reply-To: <1187301258.3788.90.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <20070816215047.GA25895@redhat.com> <1187301019.3788.84.camel@oneill.fubar.dk> <1187301258.3788.90.camel@oneill.fubar.dk> Message-ID: <20070816222210.GB20282@redhat.com> On Thu, Aug 16, 2007 at 05:54:18PM -0400, David Zeuthen wrote: > > On Thu, 2007-08-16 at 17:50 -0400, David Zeuthen wrote: > > On Thu, 2007-08-16 at 17:50 -0400, Dave Jones wrote: > > > On Thu, Aug 16, 2007 at 05:27:17PM -0400, David Zeuthen wrote: > > > > > > > > On Thu, 2007-08-16 at 10:17 +0200, Nils Philippsen wrote: > > > > > As a side point, everybody should be using LVM. Directly operating on > > > > > partitions is so 1980. > > > > > > > > Speaking as a developer, you can't boot a kernel from your home directory > > > > if /home is on LVM. > > > > > > wtf, why would you do that? Given you need to install modules > > > outside of your homedir in /lib anyway, is putting the kernel > > > into /boot so hard? > > > > I just build everything in (except the bits I'm hacking on); makes it > > much faster to compile too. To each their own I guess. > > Ugh, replying to myself again. s/everything/everything I need for the > particular box I'm using/. I don't get it. What does destination of built binaries have to do with compile time ? Dave -- http://www.codemonkey.org.uk From davidz at redhat.com Fri Aug 17 00:41:39 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 16 Aug 2007 20:41:39 -0400 Subject: low-hanging fruit In-Reply-To: <20070816222210.GB20282@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <20070816215047.GA25895@redhat.com> <1187301019.3788.84.camel@oneill.fubar.dk> <1187301258.3788.90.camel@oneill.fubar.dk> <20070816222210.GB20282@redhat.com> Message-ID: <1187311299.2943.7.camel@oneill.fubar.dk> On Thu, 2007-08-16 at 18:22 -0400, Dave Jones wrote: > > > I just build everything in (except the bits I'm hacking on); makes it > > > much faster to compile too. To each their own I guess. > > > > Ugh, replying to myself again. s/everything/everything I need for the > > particular box I'm using/. > > I don't get it. What does destination of built binaries have to > do with compile time ? I was just clarifying what I meant with "I just build everything in" to explain that by doing what I do, I gain the ability to a) boot the kernel image directly from my home directory (w/o initramfs); and b) it's much faster to compile since I don't have to build lots of drivers I don't need; and c) I can have a static grub entry pointing into my home directory. FWIW, I'm not the only one who does this. David From katzj at redhat.com Fri Aug 17 00:48:20 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Aug 2007 20:48:20 -0400 Subject: low-hanging fruit In-Reply-To: <1187298473.3788.68.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214750.6003.2.camel@localhost.localdomain> <1187298473.3788.68.camel@oneill.fubar.dk> Message-ID: <1187311700.637.14.camel@localhost.localdomain> On Thu, 2007-08-16 at 17:07 -0400, David Zeuthen wrote: > Jeremy, any chance we can change anaconda such that we can slap a > simpler UI, decoupled from the actual mechanism, on top of it? Thanks. Like I told you six months ago -- write a kickstart generator, pass that, voila, you have control of your own destiny. There's even pykickstart to make it so that you don't have to worry about what the actual kickstart config syntax is. That's going to be the simplest route. The other route would be creating another interface in addition to the text, line oriented (think crappy s390 consoles) and current gui interface and plugging it in. Not hard either, but a kickstart config is going to be easier and should be sufficient Jeremy From bnocera at redhat.com Fri Aug 17 01:30:17 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 17 Aug 2007 02:30:17 +0100 Subject: low-hanging fruit In-Reply-To: <20070816141730.3356f3c3@mentok.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <1187284974.17169.4.camel@localhost.localdomain> <1187287477.2718.31.camel@localhost.localdomain> <1187287835.17169.13.camel@localhost.localdomain> <20070816141730.3356f3c3@mentok.boston.redhat.com> Message-ID: <1187314217.26239.34.camel@cookie.hadess.net> On Thu, 2007-08-16 at 14:17 -0400, Jesse Keating wrote: > On Thu, 16 Aug 2007 14:10:35 -0400 > Jeremy Katz wrote: > > > I'm not against it. The complaint will be that people will just get > > failures and not have anything to show them why. Maybe we can get the > > quick change into the default firewall rules so that they'll log > > failures so that it's not at least entirely silent > > +10, that's the most annoying thing to me about our default rules. > It's so silent. If we're afraid of it drowning out /var/log/messages > we could send it to a firewall log file. But I'm all for dropping > these from Firstboot and going with our defaults. > > Anybody for firewall2allow? (: Maybe Lennart can fix it too? :) Here's an old entry in my bookmarks: http://0pointer.de/lennart/projects/fieryfilter/ http://0pointer.de/lennart/projects/fieryfilter/fieryfilter.png This probably needs UI love, and use of D-Bus instead of Unix sockets for the admin rights, but the idea is there. From nicu_fedora at nicubunu.ro Fri Aug 17 05:40:02 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 17 Aug 2007 08:40:02 +0300 Subject: low-hanging fruit In-Reply-To: <1187280287.2718.17.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> Message-ID: <46C534B2.2050705@nicubunu.ro> Jonathan Blandford wrote: > > Might be less low-hanging fruit, but give firstboot a quick look: > - user icon as part of new user creation But the result of this is that the person choosing the user icon is the administrator, not the user itself so the user will have to change the icon again. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From mclasen at redhat.com Fri Aug 17 05:51:40 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Aug 2007 01:51:40 -0400 Subject: low-hanging fruit In-Reply-To: <46C534B2.2050705@nicubunu.ro> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <46C534B2.2050705@nicubunu.ro> Message-ID: <1187329900.6476.5.camel@localhost.localdomain> On Fri, 2007-08-17 at 08:40 +0300, Nicu Buculei wrote: > Jonathan Blandford wrote: > > > > Might be less low-hanging fruit, but give firstboot a quick look: > > - user icon as part of new user creation > > But the result of this is that the person choosing the user icon is the > administrator, not the user itself so the user will have to change the > icon again. > We are talking about the desktop scenario here, where there is no administrator around. From skvidal at fedoraproject.org Fri Aug 17 05:52:52 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 17 Aug 2007 01:52:52 -0400 Subject: low-hanging fruit In-Reply-To: <1187329900.6476.5.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <46C534B2.2050705@nicubunu.ro> <1187329900.6476.5.camel@localhost.localdomain> Message-ID: <1187329972.31261.7.camel@cutter> On Fri, 2007-08-17 at 01:51 -0400, Matthias Clasen wrote: > On Fri, 2007-08-17 at 08:40 +0300, Nicu Buculei wrote: > > Jonathan Blandford wrote: > > > > > > Might be less low-hanging fruit, but give firstboot a quick look: > > > - user icon as part of new user creation > > > > But the result of this is that the person choosing the user icon is the > > administrator, not the user itself so the user will have to change the > > icon again. > > > > We are talking about the desktop scenario here, where there is no > administrator around. umm, what? Lots of machines that are desktops have administrators. -sv From nicu_fedora at nicubunu.ro Fri Aug 17 05:53:55 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 17 Aug 2007 08:53:55 +0300 Subject: low-hanging fruit In-Reply-To: <1187329900.6476.5.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <46C534B2.2050705@nicubunu.ro> <1187329900.6476.5.camel@localhost.localdomain> Message-ID: <46C537F3.3040701@nicubunu.ro> Matthias Clasen wrote: > On Fri, 2007-08-17 at 08:40 +0300, Nicu Buculei wrote: >> Jonathan Blandford wrote: >>> Might be less low-hanging fruit, but give firstboot a quick look: >>> - user icon as part of new user creation >> But the result of this is that the person choosing the user icon is the >> administrator, not the user itself so the user will have to change the >> icon again. >> > > We are talking about the desktop scenario here, where there is no > administrator around. But the user can share the computer with with wife/kids/roommate. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From mclasen at redhat.com Fri Aug 17 06:14:22 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Aug 2007 02:14:22 -0400 Subject: low-hanging fruit In-Reply-To: <1187329972.31261.7.camel@cutter> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <46C534B2.2050705@nicubunu.ro> <1187329900.6476.5.camel@localhost.localdomain> <1187329972.31261.7.camel@cutter> Message-ID: <1187331262.6476.11.camel@localhost.localdomain> On Fri, 2007-08-17 at 01:52 -0400, seth vidal wrote: > On Fri, 2007-08-17 at 01:51 -0400, Matthias Clasen wrote: > > On Fri, 2007-08-17 at 08:40 +0300, Nicu Buculei wrote: > > > Jonathan Blandford wrote: > > > > > > > > Might be less low-hanging fruit, but give firstboot a quick look: > > > > - user icon as part of new user creation > > > > > > But the result of this is that the person choosing the user icon is the > > > administrator, not the user itself so the user will have to change the > > > icon again. > > > > > > > We are talking about the desktop scenario here, where there is no > > administrator around. > > umm, what? > > Lots of machines that are desktops have administrators. I assume those are not installed from a live cd, though. The very common use case that we are talking about here is that a machine is being installed from a live cd, by the same person who is going to use this machine afterwards. Most likely this is happening in the living room, not in the cube farm at work. From mclasen at redhat.com Fri Aug 17 06:16:21 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Aug 2007 02:16:21 -0400 Subject: low-hanging fruit In-Reply-To: <46C537F3.3040701@nicubunu.ro> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <46C534B2.2050705@nicubunu.ro> <1187329900.6476.5.camel@localhost.localdomain> <46C537F3.3040701@nicubunu.ro> Message-ID: <1187331381.6476.13.camel@localhost.localdomain> On Fri, 2007-08-17 at 08:53 +0300, Nicu Buculei wrote: > Matthias Clasen wrote: > > On Fri, 2007-08-17 at 08:40 +0300, Nicu Buculei wrote: > >> Jonathan Blandford wrote: > >>> Might be less low-hanging fruit, but give firstboot a quick look: > >>> - user icon as part of new user creation > >> But the result of this is that the person choosing the user icon is the > >> administrator, not the user itself so the user will have to change the > >> icon again. > >> > > > > We are talking about the desktop scenario here, where there is no > > administrator around. > > But the user can share the computer with with wife/kids/roommate. Sure he can. How does that negate the idea of letting him pick his icon/take a use photo with his webcam when he is setting up his account in firstboot ? From nicu_fedora at nicubunu.ro Fri Aug 17 07:04:46 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 17 Aug 2007 10:04:46 +0300 Subject: low-hanging fruit In-Reply-To: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: <46C5488E.7020500@nicubunu.ro> Matthias Clasen wrote: > As discussed in the meeting, here is my personal > "laundry list" of low-hanging fruit. Note that some of > these are being worked on for F8 anyway. I think I can propose another item: take a lesson from ccLiveContent and include a little free multimedia content (free as in CC-BY-SA) in the default install to show the user the multimedia capabilities. This can be 2 or 3 songs in Ogg Vorbis format and 1 or 2 videos in Ogg Theora. It does not matter *what* the content it, the videos may be RH commercials, interviews with OLPC developers, FUDcon footage, whatever as long as is shiny and can be played right away. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From nphilipp at redhat.com Fri Aug 17 09:37:21 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 17 Aug 2007 11:37:21 +0200 Subject: low-hanging fruit In-Reply-To: <1187300197.3788.81.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> Message-ID: <1187343441.31744.22.camel@wombat.tiptoe.de> On Thu, 2007-08-16 at 17:36 -0400, David Zeuthen wrote: > On Thu, 2007-08-16 at 17:27 -0400, David Zeuthen wrote: > > On Thu, 2007-08-16 at 10:17 +0200, Nils Philippsen wrote: > > > As a side point, everybody should be using LVM. Directly operating on > > > partitions is so 1980. > > > > Speaking as a developer, you can boot a kernel from your home directory > ^^^^ > I meant can't of course. Sorry. > > > if /home is on LVM. Hence, LVM is definitely something to avoid for more > > developer oriented flavors on Fedora. Speaking as a developer as well, I don't think the use case you describe is as widespread as you think it is. Compare your "David" persona to my "Manolo" one who just wants to build another kernel with some unnamed patch that won't ever make it upstream (or into Fedora) and needs another half gig of space quickly but his /home is filled up to only 150 megs being free due to all the movies he recorded with his DVB card. Now with LVM, "Manolo" can do: lv_extend -L +1G /dev/VolGroup00/LogVol01 resize2fs -p /dev/VolGroup00/LogVol01 After about a minute -- if you count in time to read man pages, perhaps less if there's a tool that let's him tdo that in a GUI -- he's ready for another round of kernel building. Don't you think that having to "sudo cp vmlinuz /boot" isn't too much a hassle for "David" compared to the benefits for "Manolo"? It's Friday after all, so don't automatically assume that you're the target audience ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From jkeating at redhat.com Fri Aug 17 11:47:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 07:47:31 -0400 Subject: low-hanging fruit In-Reply-To: <1187314217.26239.34.camel@cookie.hadess.net> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <1187284974.17169.4.camel@localhost.localdomain> <1187287477.2718.31.camel@localhost.localdomain> <1187287835.17169.13.camel@localhost.localdomain> <20070816141730.3356f3c3@mentok.boston.redhat.com> <1187314217.26239.34.camel@cookie.hadess.net> Message-ID: <20070817074731.6c34b304@ender> On Fri, 17 Aug 2007 02:30:17 +0100 Bastien Nocera wrote: > Maybe Lennart can fix it too? :) > > Here's an old entry in my bookmarks: > http://0pointer.de/lennart/projects/fieryfilter/ > http://0pointer.de/lennart/projects/fieryfilter/fieryfilter.png > > This probably needs UI love, and use of D-Bus instead of Unix sockets > for the admin rights, but the idea is there. Actually I find these questions to be a net lose. Just like the ssl cert questions in browsers. They're scray questions in languages the user either doesn't understand or just plain doesn't care about. (and no, I don't have a better suggestion to solve the problem) -- 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 bnocera at redhat.com Fri Aug 17 12:44:23 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 17 Aug 2007 13:44:23 +0100 Subject: low-hanging fruit In-Reply-To: <20070817074731.6c34b304@ender> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <1187284974.17169.4.camel@localhost.localdomain> <1187287477.2718.31.camel@localhost.localdomain> <1187287835.17169.13.camel@localhost.localdomain> <20070816141730.3356f3c3@mentok.boston.redhat.com> <1187314217.26239.34.camel@cookie.hadess.net> <20070817074731.6c34b304@ender> Message-ID: <1187354663.26239.41.camel@cookie.hadess.net> On Fri, 2007-08-17 at 07:47 -0400, Jesse Keating wrote: > On Fri, 17 Aug 2007 02:30:17 +0100 > Bastien Nocera wrote: > > > Maybe Lennart can fix it too? :) > > > > Here's an old entry in my bookmarks: > > http://0pointer.de/lennart/projects/fieryfilter/ > > http://0pointer.de/lennart/projects/fieryfilter/fieryfilter.png > > > > This probably needs UI love, and use of D-Bus instead of Unix sockets > > for the admin rights, but the idea is there. > > Actually I find these questions to be a net lose. Just like the ssl > cert questions in browsers. They're scray questions in languages the > user either doesn't understand or just plain doesn't care about. (and > no, I don't have a better suggestion to solve the problem) I was mostly talking about the infrastructure that this provides. and I mentioned the UI needs love. It would allow us to do something like that: http://www.wap.org/journal/security3/firewall.jpg Or better, allow HTTP on a specific port when personal sharing is on, etc. Without the infrastructure, we end up with full firewall logs, and no user feedback. From katzj at redhat.com Fri Aug 17 13:36:18 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 17 Aug 2007 09:36:18 -0400 Subject: low-hanging fruit In-Reply-To: <46C534B2.2050705@nicubunu.ro> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <46C534B2.2050705@nicubunu.ro> Message-ID: <1187357779.18195.2.camel@erebor.boston.redhat.com> On Fri, 2007-08-17 at 08:40 +0300, Nicu Buculei wrote: > Jonathan Blandford wrote: > > > > Might be less low-hanging fruit, but give firstboot a quick look: > > - user icon as part of new user creation > > But the result of this is that the person choosing the user icon is the > administrator, not the user itself so the user will have to change the > icon again. A key point here is we're talking about firstboot -- where one user is being created, likely the admin's actual account. And on a desktop box. And if you don't change the face, then it just stays the default one. Eventually, yes, would be good to do in general -- but the real low-hanging fruit is to get it into firstboot Jeremy From davej at redhat.com Fri Aug 17 13:37:26 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 17 Aug 2007 09:37:26 -0400 Subject: low-hanging fruit In-Reply-To: <1187354663.26239.41.camel@cookie.hadess.net> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <1187284974.17169.4.camel@localhost.localdomain> <1187287477.2718.31.camel@localhost.localdomain> <1187287835.17169.13.camel@localhost.localdomain> <20070816141730.3356f3c3@mentok.boston.redhat.com> <1187314217.26239.34.camel@cookie.hadess.net> <20070817074731.6c34b304@ender> <1187354663.26239.41.camel@cookie.hadess.net> Message-ID: <20070817133725.GA3534@redhat.com> On Fri, Aug 17, 2007 at 01:44:23PM +0100, Bastien Nocera wrote: > On Fri, 2007-08-17 at 07:47 -0400, Jesse Keating wrote: > > On Fri, 17 Aug 2007 02:30:17 +0100 > > Bastien Nocera wrote: > > > > > Maybe Lennart can fix it too? :) > > > > > > Here's an old entry in my bookmarks: > > > http://0pointer.de/lennart/projects/fieryfilter/ > > > http://0pointer.de/lennart/projects/fieryfilter/fieryfilter.png > > > > > > This probably needs UI love, and use of D-Bus instead of Unix sockets > > > for the admin rights, but the idea is there. > > > > Actually I find these questions to be a net lose. Just like the ssl > > cert questions in browsers. They're scray questions in languages the > > user either doesn't understand or just plain doesn't care about. (and > > no, I don't have a better suggestion to solve the problem) > > I was mostly talking about the infrastructure that this provides. and I > mentioned the UI needs love. It would allow us to do something like > that: > http://www.wap.org/journal/security3/firewall.jpg This looks fairly sensible. From the look of the png above though, it pops up a dialog for every packet that doesn't match the rules? That sounds like a *really* bad idea. Dave -- http://www.codemonkey.org.uk From davidz at redhat.com Fri Aug 17 15:21:54 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 17 Aug 2007 11:21:54 -0400 Subject: low-hanging fruit In-Reply-To: <1187343441.31744.22.camel@wombat.tiptoe.de> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> Message-ID: <1187364114.9814.50.camel@oneill.fubar.dk> On Fri, 2007-08-17 at 11:37 +0200, Nils Philippsen wrote: > Speaking as a developer as well, I don't think the use case you describe > is as widespread as you think it is. > > Compare your "David" persona to my "Manolo" one who just wants to build > another kernel with some unnamed patch that won't ever make it upstream > (or into Fedora) and needs another half gig of space quickly but > his /home is filled up to only 150 megs being free due to all the movies > he recorded with his DVB card. Now with LVM, "Manolo" can do: > > lv_extend -L +1G /dev/VolGroup00/LogVol01 > resize2fs -p /dev/VolGroup00/LogVol01 > > After about a minute -- if you count in time to read man pages, perhaps > less if there's a tool that let's him tdo that in a GUI -- he's ready > for another round of kernel building. Don't you think that having to > "sudo cp vmlinuz /boot" isn't too much a hassle for "David" compared to > the benefits for "Manolo"? Yes, I've read http://tldp.org/HOWTO/LVM-HOWTO/extendlv.html and am well aware of LVM. You make several assumptions here: 1) that /home is on a separate partition; 2) that there actually is space somewhere to add to /home. So it's not at all as easy as you make it look. Lots of assumptions. One way to avoid such scenarios is just avoid having multiple file systems; e.g. for a desktop distro it's probably sane to only a single file system. I'm not opposed to using LVM for this (so people can add a 2nd hard disk though this is really a corner case) or... some day in a star trek future a file system like ZFS / btrfs / whatever with storage pool support etc. I simply just want to avoid asking techno babble questions in the installer; I just want a simple slider with "HOW MUCH FEDORA CAN YOU HANDLE" as I posted in the other mail. No techno babble. However, again, that does _not_ mean we can't use LVM or whatever under the covers if we want to. But it's only really going to be useful if you have 2nd hard disk in your system and I think the percentage of our demographic where that is true at any point in time is pretty low. Your point about the lack of decent UI tools to do this is a good one however. Ideally there should be a single point in the UI where some user can click a button "add this harddrive to my system" and the right thing just happens. > It's Friday after all, so don't automatically assume that you're the > target audience ;-). It's funny you bring this up. Apparently members of your target audience knows how to use LVM (and hopefully they know that it's lvextend, not lv_extend :-).... and is able to make a distinction between a PV, LV and VG's? Or.. wait.. maybe they follow one of the "HOWTO's" out there and maybe get it right the 2nd or 3rd time they try. I certainly have blown up my PV's and LV's playing around with LVM.. Right.. Also.. it's supposed to be "fun" and "we learn about Linux" dealing with UNIX command line tools specifically designed to be unforgiving [1]. Right... _that_ target audience. I don't think so. So while that target audience may be OK for mainline Fedora where administrators are installing servers and workstations in enterprises / whatever and know what they're doing, I don't think it's fine for what we're talking about here: A derivative of Fedora intended for human beings using ths OS on laptops / home desktop systems. Please don't throw techno babble at them. This is one of the crucial differences we need to make between mainline Fedora and what we're doing here. That we specifically can assume that the user is not an expert administrator. David [1] : I can't find the link / quote here but UNIX commandline tools are designed to be mostly hostile / unforgiving; e.g. actually do what the user wants because they assume that the user is actually an expert. While that's good for experts.. it's not really good for novices who just wants to get the job done. From jkeating at redhat.com Fri Aug 17 15:27:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 11:27:16 -0400 Subject: low-hanging fruit In-Reply-To: <1187364114.9814.50.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> Message-ID: <20070817112716.5e9367a3@ender> On Fri, 17 Aug 2007 11:21:54 -0400 David Zeuthen wrote: > Apparently members of your target audience knows how to use LVM (and > hopefully they know that it's lvextend, not lv_extend :-).... and is > able to make a distinction between a PV, LV and VG's? Or.. wait.. > maybe they follow one of the "HOWTO's" out there and maybe get it > right the 2nd or 3rd time they try. I certainly have blown up my PV's > and LV's playing around with LVM.. Right.. Also.. it's supposed to be > "fun" and "we learn about Linux" dealing with UNIX command line tools > specifically designed to be unforgiving [1]. Right... _that_ target > audience. > > I don't think so. To be fair, system-config-lvm has come a long way recently and is quite usable I'm told, and not at all unfriendly. -- 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 katzj at redhat.com Fri Aug 17 15:33:09 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 17 Aug 2007 11:33:09 -0400 Subject: low-hanging fruit In-Reply-To: <1187364114.9814.50.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> Message-ID: <1187364789.18195.11.camel@erebor.boston.redhat.com> On Fri, 2007-08-17 at 11:21 -0400, David Zeuthen wrote: > So while that target audience may be OK for mainline Fedora where > administrators are installing servers and workstations in enterprises / > whatever and know what they're doing, I don't think it's fine for what > we're talking about here: A derivative of Fedora intended for human > beings using ths OS on laptops / home desktop systems. Please don't > throw techno babble at them. Human beings don't compile kernels either, so ... :-) Jeremy From davidz at redhat.com Fri Aug 17 15:56:56 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 17 Aug 2007 11:56:56 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <1187364789.18195.11.camel@erebor.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> Message-ID: <1187366216.9814.72.camel@oneill.fubar.dk> On Fri, 2007-08-17 at 11:33 -0400, Jeremy Katz wrote: > On Fri, 2007-08-17 at 11:21 -0400, David Zeuthen wrote: > > So while that target audience may be OK for mainline Fedora where > > administrators are installing servers and workstations in enterprises / > > whatever and know what they're doing, I don't think it's fine for what > > we're talking about here: A derivative of Fedora intended for human > > beings using ths OS on laptops / home desktop systems. Please don't > > throw techno babble at them. > > Human beings don't compile kernels either, so ... :-) The real point I was tried to make was about the target audience: if we want to make a difference with this new derived distribution we need to have a target audience and optimize the experience for this audience instead of the rather direction-less "catch-all-audiences" thing we've been doing with Fedora so far. I've already given my $0.02 about what that target audience could be: people who are not computer experts. That's just my suggestion, I expect others have other ideas and we should discuss on this list and converge on something and write it into the charter for the SIG. It's important. So we need to define the target audience. And it's not necessarily bad, people shouldn't be all "Oh, screw you desktop guys, I'm not part of the target audience, I'll never use this thing"; I mean, even hard core people like yourself, davej or notting still have laptops where this is only a single OS installed and you'll probably never need any LVM or RAID features. So at the same time we should be inclusive to other audiences, e.g. just because we're optimizing parts of the OS for people like my someones mom, it does not mean that it's not suitable for certain applications by e.g. hard core developers. David From walters at redhat.com Fri Aug 17 16:40:27 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 17 Aug 2007 12:40:27 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <1187366216.9814.72.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> Message-ID: On 8/17/07, David Zeuthen wrote: > > > I've already given my $0.02 about what that target audience could be: > people who are not computer experts. I agree with you and think it probably makes sense to do the "XP/OSX replacement" type desktop, if only because we've been vaguely trying to do that so far. But I'd also like to see us figure out how to explicitly go for developers. In particular, web site developers. I want a version of the Fedora desktop that I can hand to my friend who has the idea for the next great website. "Here, this comes Ruby on Rails set up out of the box, Eclipse with Web development tools, Wireshark, etc." No OpenOffice Then also make it easy to deploy a Fedora server with your changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zcerza at redhat.com Fri Aug 17 17:04:10 2007 From: zcerza at redhat.com (Zack Cerza) Date: Fri, 17 Aug 2007 13:04:10 -0400 Subject: low-hanging fruit In-Reply-To: <1187299998.3788.79.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> <1187299998.3788.79.camel@oneill.fubar.dk> Message-ID: <46C5D50A.9060109@redhat.com> David Zeuthen wrote: > On Thu, 2007-08-16 at 09:06 +0300, Nicu Buculei wrote: >> Matthias Clasen wrote: >>> - reconsider default panel config (launchers) >> This is something I think is badly needed, for quite some time I wanted >> to talk about this but was not bold enough to bring the topic out so far. >> I think is about the time for the OpenOffice.org icons to go away from >> the default panel, they were useful some years ago to inform people >> Fedora has a capable Office Suite, but by now everybody know and expect >> this and an office suite is boring. >> I think those launchers would be better replaced by something people >> like: multimedia, at least a launcher for Rhythmbox and maybe something >> people really use (usage stats gathered from Mugshot, but this would >> suggest a launcher for the terminal as very desired). > > +1 for doing this; in the same breath we should depart from having the > generic web browser launcher in the panel and instead just add the > Firefox launcher or whatever default browser we ship [1]. Definitely > something we can and should do in this release. > > David > > [1] : IIRC the reason for the generic launcher is that the program it > launches actually picks the browser from your choice made in the > "Preferred Applications" caplet. Ie. the thinking, or so I was > explained, is that if you change your browser in "Preferred > Applications", the launcher will respect that choice. > > However, I think the price of having that eyesore is too high; users who > know how to go into "Preferred Applications" are most likely more than > capable of removing the Firefox launcher from their panel. It'd be even better if that launcher would simply display the name and icon of your preferred browser. :) Zack From bill at pecknet.com Fri Aug 17 17:18:21 2007 From: bill at pecknet.com (Bill Peck) Date: Fri, 17 Aug 2007 13:18:21 -0400 Subject: low-hanging fruit In-Reply-To: <46C5D50A.9060109@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> <1187299998.3788.79.camel@oneill.fubar.dk> <46C5D50A.9060109@redhat.com> Message-ID: On 8/17/07, Zack Cerza wrote: > It'd be even better if that launcher would simply display the name and > icon of your preferred browser. :) > > Zack > > -- it would have to be an applet then? From zcerza at redhat.com Fri Aug 17 17:22:27 2007 From: zcerza at redhat.com (Zack Cerza) Date: Fri, 17 Aug 2007 13:22:27 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> <1187299998.3788.79.camel@oneill.fubar.dk> <46C5D50A.9060109@redhat.com> Message-ID: <46C5D953.1080301@redhat.com> Bill Peck wrote: > On 8/17/07, Zack Cerza wrote: > >> It'd be even better if that launcher would simply display the name and >> icon of your preferred browser. :) >> >> Zack >> >> -- > > it would have to be an applet then? > Well, sure. I don't know if that's feasible, but it sure doesn't *seem* hard :) From jon.nettleton at gmail.com Fri Aug 17 17:36:33 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 17 Aug 2007 13:36:33 -0400 Subject: low-hanging fruit In-Reply-To: <46C5D953.1080301@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> <1187299998.3788.79.camel@oneill.fubar.dk> <46C5D50A.9060109@redhat.com> <46C5D953.1080301@redhat.com> Message-ID: On 8/17/07, Zack Cerza wrote: > > Bill Peck wrote: > > On 8/17/07, Zack Cerza wrote: > > > >> It'd be even better if that launcher would simply display the name and > >> icon of your preferred browser. :) > >> > >> Zack > >> > >> -- > > > > it would have to be an applet then? > > > > Well, sure. I don't know if that's feasible, but it sure doesn't *seem* > hard :) I was thinking about this the other day. I think the gnome-panel needs a launcher applet that is more configurable. One of the features should be "sticky launchers", another feature would be to auto-add either most used, or recently used launchers. Suse and Ubuntu seem set on adding this functionality in an enormous SLAB menu. I think a small gnome applet makes a lot more sense. Right now I just don't have the time to work on it, unfortunately. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Fri Aug 17 17:43:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 13:43:25 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> <1187299998.3788.79.camel@oneill.fubar.dk> <46C5D50A.9060109@redhat.com> <46C5D953.1080301@redhat.com> Message-ID: <20070817134325.5ded087f@ender> On Fri, 17 Aug 2007 13:36:33 -0400 "Jon Nettleton" wrote: > I was thinking about this the other day. I think the gnome-panel > needs a launcher applet that is more configurable. One of the > features should be "sticky launchers", another feature would be to > auto-add either most used, or recently used launchers. That sounds like BigBoard. -- 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 mclasen at redhat.com Fri Aug 17 18:11:57 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Aug 2007 14:11:57 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> <1187299998.3788.79.camel@oneill.fubar.dk> <46C5D50A.9060109@redhat.com> <46C5D953.1080301@redhat.com> Message-ID: <1187374322.1161.39.camel@localhost.localdomain> On Fri, 2007-08-17 at 13:36 -0400, Jon Nettleton wrote: > > Suse and Ubuntu seem set on adding this functionality in an enormous > SLAB menu. Yeah, we are going in a similar direction with bigboard. > I think a small gnome applet makes a lot more sense. Yeah, doing a "lauch preferred browser/mail client/terminal" applet should take ~20 lines of non-boilerplate code... From davej at redhat.com Fri Aug 17 18:19:51 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 17 Aug 2007 14:19:51 -0400 Subject: low-hanging fruit In-Reply-To: <1187364789.18195.11.camel@erebor.boston.redhat.com> References: <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> Message-ID: <20070817181951.GG22854@redhat.com> On Fri, Aug 17, 2007 at 11:33:09AM -0400, Jeremy Katz wrote: > On Fri, 2007-08-17 at 11:21 -0400, David Zeuthen wrote: > > So while that target audience may be OK for mainline Fedora where > > administrators are installing servers and workstations in enterprises / > > whatever and know what they're doing, I don't think it's fine for what > > we're talking about here: A derivative of Fedora intended for human > > beings using ths OS on laptops / home desktop systems. Please don't > > throw techno babble at them. > > Human beings don't compile kernels either, so ... :-) Feeling. So. Unloved. Dave -- http://www.codemonkey.org.uk From bclark at redhat.com Fri Aug 17 18:21:12 2007 From: bclark at redhat.com (Bryan Clark) Date: Fri, 17 Aug 2007 14:21:12 -0400 Subject: low-hanging fruit In-Reply-To: <20070817181951.GG22854@redhat.com> References: <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <20070817181951.GG22854@redhat.com> Message-ID: <4600a0ae0708171121t6b12019aoc08555115b3805fa@mail.gmail.com> On 8/17/07, Dave Jones wrote: > > On Fri, Aug 17, 2007 at 11:33:09AM -0400, Jeremy Katz wrote: > > On Fri, 2007-08-17 at 11:21 -0400, David Zeuthen wrote: > > > So while that target audience may be OK for mainline Fedora where > > > administrators are installing servers and workstations in enterprises > / > > > whatever and know what they're doing, I don't think it's fine for what > > > we're talking about here: A derivative of Fedora intended for human > > > beings using ths OS on laptops / home desktop systems. Please don't > > > throw techno babble at them. > > > > Human beings don't compile kernels either, so ... :-) > > Feeling. So. Unloved. I think they are trying to say you are some kind of Super Human -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Fri Aug 17 18:27:03 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 17 Aug 2007 14:27:03 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <1187366216.9814.72.camel@oneill.fubar.dk> References: <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> Message-ID: <20070817182703.GH22854@redhat.com> On Fri, Aug 17, 2007 at 11:56:56AM -0400, David Zeuthen wrote: > want to make a difference with this new derived distribution we need to > have a target audience and optimize the experience for this audience > instead of the rather direction-less "catch-all-audiences" thing we've > been doing with Fedora so far. The problem I see with defining _a_ target audience is that it by nature, precludes other audiences. We have to have at least some part of the 'catch all audiences' thing going on, or we lose a segment of our userbase to other distros which cater to their needs. > So we need to define the target audience. And it's not necessarily bad, > people shouldn't be all "Oh, screw you desktop guys, I'm not part of the > target audience, I'll never use this thing"; I mean, even hard core > people like yourself, davej or notting still have laptops where this is > only a single OS installed and you'll probably never need any LVM or > RAID features. You've not seen my two disk RAID0 laptop ? :-) [yes, I'm serious] FWIW, it always bothered me that we use LVM everywhere. In hindsight I think it was a mistake. I can see why it would make ongoing maintainence of the installer simpler, but for a lot of cases, it's utterly needless. As wonderful as I'm sure resizing volumes is, I've *never* used it. Ever. Yet near every install I do uses lvm, for no damn reason at all (other than I'm too lazy to click 'custom partitioning') Dave -- http://www.codemonkey.org.uk From mclasen at redhat.com Fri Aug 17 18:43:43 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Aug 2007 14:43:43 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <20070817182703.GH22854@redhat.com> References: <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> Message-ID: <1187376223.1161.59.camel@localhost.localdomain> On Fri, 2007-08-17 at 14:27 -0400, Dave Jones wrote: > On Fri, Aug 17, 2007 at 11:56:56AM -0400, David Zeuthen wrote: > > > want to make a difference with this new derived distribution we need to > > have a target audience and optimize the experience for this audience > > instead of the rather direction-less "catch-all-audiences" thing we've > > been doing with Fedora so far. > > The problem I see with defining _a_ target audience is that it by > nature, precludes other audiences. We have to have at least some > part of the 'catch all audiences' thing going on, or we lose a segment > of our userbase to other distros which cater to their needs. I don't think we should be too worried about losing a segment of our user base". That is the beauty of the spin concept. You can have kernel-hackers spin that is optimized for a different audience. And the really big audiences are not part of our userbase at all yet, anyway. From davej at redhat.com Fri Aug 17 19:06:56 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 17 Aug 2007 15:06:56 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <1187376223.1161.59.camel@localhost.localdomain> References: <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> <1187376223.1161.59.camel@localhost.localdomain> Message-ID: <20070817190656.GA22004@redhat.com> On Fri, Aug 17, 2007 at 02:43:43PM -0400, Matthias Clasen wrote: > > On Fri, 2007-08-17 at 14:27 -0400, Dave Jones wrote: > > On Fri, Aug 17, 2007 at 11:56:56AM -0400, David Zeuthen wrote: > > > > > want to make a difference with this new derived distribution we need to > > > have a target audience and optimize the experience for this audience > > > instead of the rather direction-less "catch-all-audiences" thing we've > > > been doing with Fedora so far. > > > > The problem I see with defining _a_ target audience is that it by > > nature, precludes other audiences. We have to have at least some > > part of the 'catch all audiences' thing going on, or we lose a segment > > of our userbase to other distros which cater to their needs. > > I don't think we should be too worried about losing a segment of our > user base". That is the beauty of the spin concept. You can have > kernel-hackers spin that is optimized for a different audience. > And the really big audiences are not part of our userbase at all yet, > anyway. Don't be so sure. Indirectly, there's at least one target audience where Fedora is wiping the floor with the competition :-) http://kernelslacker.livejournal.com/89041.html I'm not sure what level of testing we'd need to do for that spin though. Dave -- http://www.codemonkey.org.uk From sandmann at redhat.com Fri Aug 17 19:13:57 2007 From: sandmann at redhat.com (Soeren Sandmann Pedersen) Date: 17 Aug 2007 15:13:57 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <20070817182703.GH22854@redhat.com> References: <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> Message-ID: Dave Jones writes: > On Fri, Aug 17, 2007 at 11:56:56AM -0400, David Zeuthen wrote: > > > want to make a difference with this new derived distribution we need to > > have a target audience and optimize the experience for this audience > > instead of the rather direction-less "catch-all-audiences" thing we've > > been doing with Fedora so far. > > The problem I see with defining _a_ target audience is that it by > nature, precludes other audiences. We have to have at least some > part of the 'catch all audiences' thing going on, or we lose a segment > of our userbase to other distros which cater to their needs. Fedora already excludes people, for example Gentoo users. They want to compile everything with CFLAGS tailored to their system, and Fedora is not helpful to them at all. The desire to use ricer CFLAGS is a _legitimate_ one. You can argue (and I'd agree) that it is largely a waste of time, but clearly some people disagree, and placebo really does work. That doesn't mean Fedora should support it. It's perfectly fine to say "Fedora is not for you, maybe Gentoo or Slackware are better choices". If it means Fedora can spend more time on things that actually matter to more people, then it's a win for everybody involved. If you agree that excluding Gentoo users is the right decision, then the question is not "do we exclude people?", but "who do we exclude?" If Fedora is the "fast-moving, innovative desktop" which is always first with new, exciting technology, then you exclude people who don't want to be guinea pigs. That is a fine decision, but people then need to realize that the userbase is then *inherently* smaller than Ubuntu's and "becoming more popular than Ubuntu" will not be possible. On the other hand "Not computer expert" is not a target since it fits 99% of the world and basically only serves to exclude current users. Soren From davej at redhat.com Fri Aug 17 19:42:25 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 17 Aug 2007 15:42:25 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: References: <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> Message-ID: <20070817194225.GA25394@redhat.com> On Fri, Aug 17, 2007 at 03:13:57PM -0400, Soeren Sandmann Pedersen wrote: > Dave Jones writes: > > The problem I see with defining _a_ target audience is that it by > > nature, precludes other audiences. We have to have at least some > > part of the 'catch all audiences' thing going on, or we lose a segment > > of our userbase to other distros which cater to their needs. > > Fedora already excludes people, for example Gentoo users. They want to > compile everything with CFLAGS tailored to their system, and Fedora is > not helpful to them at all. > ... > If you agree that excluding Gentoo users is the right decision, then > the question is not "do we exclude people?", but "who do we exclude?" There's a difference between excluding people who are already onboard with Fedora, and those who aren't. Gentoo users would fall into the latter. "Hey this used to work, now it doesn't" is what leads people to abandon distros and go looking for one that does what they came to expect. Dave -- http://www.codemonkey.org.uk From davidz at redhat.com Fri Aug 17 19:48:43 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 17 Aug 2007 15:48:43 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <20070817194225.GA25394@redhat.com> References: <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> <20070817194225.GA25394@redhat.com> Message-ID: <1187380123.9814.138.camel@oneill.fubar.dk> On Fri, 2007-08-17 at 15:42 -0400, Dave Jones wrote: > There's a difference between excluding people who are already onboard > with Fedora, and those who aren't. Gentoo users would fall into the > latter. > > "Hey this used to work, now it doesn't" is what leads people to abandon > distros and go looking for one that does what they came to expect. I'm not sure what you're saying... Are you're saying we should stay with the status quo that is Fedora today (no direction, yay!) and avoid trying to do a derivative of Fedora that is targeted against some users? It's not like mainline Fedora is going away... David From caillon at redhat.com Fri Aug 17 19:53:30 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 17 Aug 2007 15:53:30 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <20070817194225.GA25394@redhat.com> References: <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> <20070817194225.GA25394@redhat.com> Message-ID: <46C5FCBA.30300@redhat.com> Dave Jones wrote: > There's a difference between excluding people who are already onboard > with Fedora, and those who aren't. Gentoo users would fall into the > latter. > > "Hey this used to work, now it doesn't" is what leads people to abandon > distros and go looking for one that does what they came to expect. But it still will work the way they want. This is a targeted spin which has not existed before. If people want to use it, they can. If not, the main Fedora spin will continue to meet their expectations. From stevelist at silverorange.com Fri Aug 17 20:01:35 2007 From: stevelist at silverorange.com (Steven Garrity) Date: Fri, 17 Aug 2007 17:01:35 -0300 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <1187366216.9814.72.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> Message-ID: <46C5FE9F.8070404@silverorange.com> When discussing the idea of a target audience, I find Firefox to be a valuable example. What is the target audience of Firefox? Originally (I assume), the early Firefox developers were just sick of the old Mozilla browser and wanted something "better." What they ended up with turned out to be better for experienced web-developers, and first-time web users. Sometimes, better is just better. Someone said in the IRC meeting the other day (paraphrasing) that there is enough that obviously needs improvement before we start prioritizing for different audiences. If you're a kernel developer, a graphic designer, or a hotmail-user with their first Dell, you still want your computer to boot up quickly, for your iPod to work, and for things to look and feel solid and polished. Cheers, Steven Garrity From davej at redhat.com Fri Aug 17 20:01:48 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 17 Aug 2007 16:01:48 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <46C5FCBA.30300@redhat.com> References: <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> <20070817194225.GA25394@redhat.com> <46C5FCBA.30300@redhat.com> Message-ID: <20070817200148.GA30879@redhat.com> On Fri, Aug 17, 2007 at 03:53:30PM -0400, Christopher Aillon wrote: > Dave Jones wrote: > > There's a difference between excluding people who are already onboard > > with Fedora, and those who aren't. Gentoo users would fall into the > > latter. > > > > "Hey this used to work, now it doesn't" is what leads people to abandon > > distros and go looking for one that does what they came to expect. > > But it still will work the way they want. This is a targeted spin which > has not existed before. Ok, I hadn't realised this. I just went back and skimmed the whole thread, and afaics this wasn't mentioned anywhere other than I guess in the meeting (that I wasn't around for). Dave -- http://www.codemonkey.org.uk From davidz at redhat.com Fri Aug 17 20:03:43 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 17 Aug 2007 16:03:43 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: References: <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> Message-ID: <1187381023.9814.147.camel@oneill.fubar.dk> On Fri, 2007-08-17 at 15:13 -0400, Soeren Sandmann Pedersen wrote: > If Fedora is the "fast-moving, innovative desktop" which is always > first with new, exciting technology, then you exclude people who don't > want to be guinea pigs. That is a fine decision, but people then need > to realize that the userbase is then *inherently* smaller than > Ubuntu's and "becoming more popular than Ubuntu" will not be possible. FWIW, I'm not sure Ubuntu is less buggy than Fedora and if you examine many earlier threads on that topic about this I'm sure you'll find sufficient evidence. > On the other hand "Not computer expert" is not a target since it fits > 99% of the world and basically only serves to exclude current > users. Seems to work fine for Ubuntu. And all you're achieving, S?ren, with that comment is just affirming another myth: that having a target audience means that you exclude other users. We _don't_ have to alienate or exclude computer experts. It's not either or. It's not black and white. If you think about it, it's mainly about messaging, and that's one thing we've surely need to fix. David From jspaleta at gmail.com Fri Aug 17 20:33:11 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 17 Aug 2007 12:33:11 -0800 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <1187381023.9814.147.camel@oneill.fubar.dk> References: <46C3734F.8010005@redhat.com> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> <1187381023.9814.147.camel@oneill.fubar.dk> Message-ID: <604aa7910708171333l20585dabo384b2fcd45c00439@mail.gmail.com> On 8/17/07, David Zeuthen wrote: > If you think about it, it's mainly about messaging, and that's > one thing we've surely need to fix. Yes, its all about messaging. Spins are an opportunity to broaden our appeal by narrowing the message(s). And let me add, that since this is a new spin being discussed, its perfectly acceptable to throw out a baby or two with the bathwater. We got enough babies to go around. We've got a large rolling faceless sea of babies. It'd be nice to focus on a few of them at a time and actually see how cute their faces are. Pick a focus, make choices that support that focus. if some of those choices end up being bad ones and the spin has to be editted in a later revision, that's OKAY. As long as we are upfront about this spin as a narrowing of focus and provide a summary of install time functionality that is missing in this spin as compared to the standard install, it's going to be OKAY. From jon.nettleton at gmail.com Fri Aug 17 21:14:17 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 17 Aug 2007 17:14:17 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <604aa7910708171333l20585dabo384b2fcd45c00439@mail.gmail.com> References: <46C3734F.8010005@redhat.com> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> <1187381023.9814.147.camel@oneill.fubar.dk> <604aa7910708171333l20585dabo384b2fcd45c00439@mail.gmail.com> Message-ID: On 8/17/07, Jeff Spaleta wrote: > > On 8/17/07, David Zeuthen wrote: > > If you think about it, it's mainly about messaging, and that's > > one thing we've surely need to fix. > > Yes, its all about messaging. Spins are an opportunity to broaden our > appeal by narrowing the message(s). And let me add, that since this > is a new spin being discussed, its perfectly acceptable to throw out a > baby or two with the bathwater. We got enough babies to go around. > We've got a large rolling faceless sea of babies. It'd be nice to > focus on a few of them at a time and actually see how cute their faces > are. > > Pick a focus, make choices that support that focus. if some of those > choices end up being bad ones and the spin has to be editted in a > later revision, that's OKAY. As long as we are upfront about this > spin as a narrowing of focus and provide a summary of install time > functionality that is missing in this spin as compared to the standard > install, it's going to be OKAY. The thought to create my own non-official Fedora spin came to mind last week, during the compositing window manager discussion. Where does the legal stand with the Fedora branding and using it for respins? I know that unapproved Fedora sites have been forced to remove the logo. Does this follow suite with unofficial respins? Would this re-spin be official, and who decides? Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Fri Aug 17 21:15:45 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 17 Aug 2007 17:15:45 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: References: <46C3734F.8010005@redhat.com> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> <1187381023.9814.147.camel@oneill.fubar.dk> <604aa7910708171333l20585dabo384b2fcd45c00439@mail.gmail.com> Message-ID: <1187385345.3208.8.camel@cutter> On Fri, 2007-08-17 at 17:14 -0400, Jon Nettleton wrote: > > The thought to create my own non-official Fedora spin came to mind > last week, during the compositing window manager discussion. Where > does the legal stand with the Fedora branding and using it for > respins? I know that unapproved Fedora sites have been forced to > remove the logo. Does this follow suite with unofficial respins? > Would this re-spin be official, and who decides? the policy is pretty good: use only packages from fedora repositories and you can use the fedora logos. add stuff from outside and you have to get rid of the fedora logos and trademarks. -sv From jon.nettleton at gmail.com Fri Aug 17 21:26:06 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 17 Aug 2007 17:26:06 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <1187385345.3208.8.camel@cutter> References: <46C3734F.8010005@redhat.com> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> <1187381023.9814.147.camel@oneill.fubar.dk> <604aa7910708171333l20585dabo384b2fcd45c00439@mail.gmail.com> <1187385345.3208.8.camel@cutter> Message-ID: On 8/17/07, seth vidal wrote: > > > On Fri, 2007-08-17 at 17:14 -0400, Jon Nettleton wrote: > > > > > The thought to create my own non-official Fedora spin came to mind > > last week, during the compositing window manager discussion. Where > > does the legal stand with the Fedora branding and using it for > > respins? I know that unapproved Fedora sites have been forced to > > remove the logo. Does this follow suite with unofficial respins? > > Would this re-spin be official, and who decides? > > the policy is pretty good: > > use only packages from fedora repositories and you can use the fedora > logos. > > add stuff from outside and you have to get rid of the fedora logos and > trademarks. very reasonable. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Fri Aug 17 21:42:37 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 17 Aug 2007 23:42:37 +0200 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <1187381023.9814.147.camel@oneill.fubar.dk> References: <46C3734F.8010005@redhat.com> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> <1187381023.9814.147.camel@oneill.fubar.dk> Message-ID: On 8/17/07, David Zeuthen wrote: > > > [..] > We _don't_ have to alienate > or exclude computer experts. It's not either or. It's not black and > white. If you think about it, it's mainly about messaging, and that's > one thing we've surely need to fix. but by dropping features users who wants to use them are excluded (ex: raid) changing defaults etc. won't hurt a "expert" because he can just change it... but if a feature simply does not exists anymore he will use something else -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Fri Aug 17 22:04:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 18:04:25 -0400 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <1187385345.3208.8.camel@cutter> References: <46C3734F.8010005@redhat.com> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> <20070817182703.GH22854@redhat.com> <1187381023.9814.147.camel@oneill.fubar.dk> <604aa7910708171333l20585dabo384b2fcd45c00439@mail.gmail.com> <1187385345.3208.8.camel@cutter> Message-ID: <20070817180425.44666d44@ender> On Fri, 17 Aug 2007 17:15:45 -0400 seth vidal wrote: > the policy is pretty good: > > use only packages from fedora repositories and you can use the fedora > logos. > > add stuff from outside and you have to get rid of the fedora logos and > trademarks. And in all cases, if you plan to distribute, A) You'll need to get sign off from the trademark owner/manager, at this point that would be the Fedora Board. B) You'll want to figure out a strategy for dealing with source. Fedora as a work is licensed under the GPLv2 and you'll need to follow said license with regard to source, either putting it up at the same time / same place, make an offer to provide source for a period of no less than 3 years, or forward an offer from another party. -- 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 gmureddu at prodigy.net.mx Thu Aug 16 13:47:08 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Thu, 16 Aug 2007 09:47:08 -0400 Subject: low-hanging fruit In-Reply-To: <46C40E68.4000509@fedoraproject.org> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> Message-ID: <46C4555C.3020202@prodigy.net.mx> Rahul Sundaram escribi?: > Gian Paolo Mureddu wrote: >> Matthias Clasen escribi?: >>> - no root user >>> >> >> Oh please no! (fine fort the LiveCD, but absolutely NOT for the >> installed version!) I recently HAD to enable the root account in a >> *buntu system as trying to do some batch stuff with BASH with for-in >> loops and stuff is FUTILE without a *proper* root account (yes, I >> tend to use quite a bit for-in loops for repetitive commands in a >> single command line). Seamless security is fine with me, but a >> *proper* account will still be needed for those where should anything >> go wrong and you require to do emergency maintenance. > > # sudo su - > > Rahul > Why do we have to 'follow suit'? GDM root login disabled is perfectly fine, adding sudo by default doesn't seem like very good idea for me, especially after my experiences with *buntu systems where the whole */sbin paths are visible to the regular users, and though many of those commands need proper authentication to do their job, there are quite a few which can run with regular UIDs. I've always thought that the presence of a proper 'root' account in Fedora and Red Hat was way better than having one "disabled". From drago01 at gmail.com Sat Aug 18 09:04:03 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 18 Aug 2007 11:04:03 +0200 Subject: low-hanging fruit In-Reply-To: <46C4555C.3020202@prodigy.net.mx> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> Message-ID: <46C6B603.3060707@gmail.com> Gian Paolo Mureddu wrote: > Why do we have to 'follow suit'? GDM root login disabled is perfectly > fine, adding sudo by default doesn't seem like very good idea for me, > especially after my experiences with *buntu systems where the whole > */sbin paths are visible to the regular users, and though many of > those commands need proper authentication to do their job, there are > quite a few which can run with regular UIDs. I've always thought that > the presence of a proper 'root' account in Fedora and Red Hat was way > better than having one "disabled". > +1 From sundaram at fedoraproject.org Sat Aug 18 11:01:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Aug 2007 16:31:12 +0530 Subject: low-hanging fruit In-Reply-To: <46C4555C.3020202@prodigy.net.mx> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> Message-ID: <46C6D178.80907@fedoraproject.org> Gian Paolo Mureddu wrote: >> Rahul >> > Why do we have to 'follow suit'? Well we have policy kit now so we can do this correctly. If you are worried about implementation issues, I expect that we will fix those in time. Rahul From nphilipp at redhat.com Sat Aug 18 11:10:27 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 18 Aug 2007 13:10:27 +0200 Subject: Defining the target audience (Was Re: low-hanging fruit) In-Reply-To: <1187366216.9814.72.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3734F.8010005@redhat.com> <1187214331.13822.186.camel@cutter> <46C376C2.9010609@redhat.com> <1187252241.28935.6.camel@wombat.tiptoe.de> <1187299637.3788.73.camel@oneill.fubar.dk> <1187300197.3788.81.camel@oneill.fubar.dk> <1187343441.31744.22.camel@wombat.tiptoe.de> <1187364114.9814.50.camel@oneill.fubar.dk> <1187364789.18195.11.camel@erebor.boston.redhat.com> <1187366216.9814.72.camel@oneill.fubar.dk> Message-ID: <1187435427.21671.20.camel@wombat.tiptoe.de> On Fri, 2007-08-17 at 11:56 -0400, David Zeuthen wrote: > The real point I was tried to make was about the target audience: if we > want to make a difference with this new derived distribution we need to > have a target audience and optimize the experience for this audience > instead of the rather direction-less "catch-all-audiences" thing we've > been doing with Fedora so far. Sorry, but so far I haven't seen how dropping LVM would optimize the experience for this audience, and using your kernel compiling requirements as an argument in favour of non-technical users muddied the waters a bit. You know, it was the "no lvm/raid in livecd installer" thing in Matthias' original posting that set me off in the beginning. Granted, he might have meant "no techno-babble when doing the disk layout" instead of "always install directly into partitions" ;-). I'm fine with having a simplified method for these people to get an installation from the live media. But I don't see how not having LVM under the hood helps them. After all, at one day their disks will be full. Then they'll want to add another disk (or let it be added by someone who doesn't risk life and limb when using a screwdriver) and use that space. With LVM we can just provide the tools where they just have to say "use (this amount from) that disk for Fedora", the tools do the pvcreate, vgextend, lvextend, resize*fs dance under the hood and presto, the user is happy. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From walters at redhat.com Sat Aug 18 15:22:40 2007 From: walters at redhat.com (Colin Walters) Date: Sat, 18 Aug 2007 11:22:40 -0400 Subject: low-hanging fruit In-Reply-To: <46C4555C.3020202@prodigy.net.mx> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> Message-ID: On 8/16/07, Gian Paolo Mureddu wrote: > > > fine, adding sudo by default doesn't seem like very good idea for me, > especially after my experiences with *buntu systems where the whole > */sbin paths are visible to the regular users, But what is a "regular" user? If you have the Vista/OSX desktop spin, "regular users" won't ever open a terminal (or really, any application other than a web browser), and so the default path is completely irrelevant. But as a developer, when I open a terminal I want ifconfig, damn it. and though many of those > commands need proper authentication to do their job, there are quite a > few which can run with regular UIDs. I've always thought that the > presence of a proper 'root' account in Fedora and Red Hat was way better > than having one "disabled". It's unclear to me how the root account being enabled or not relates to the path. Anyways, I couldn't care less about whether or not you can log in as "root". What is important is to kill password prompts, *especially* prompts for two passwords. If we killed the prompt for the updater we'd be 90% there since that's the only thing that regularly prompts (or used to) in day to day use. This forum thread fixed it for me: http://forums.fedoraforum.org/archive/index.php/t-139634.html Let's just do it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Sat Aug 18 15:33:34 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 18 Aug 2007 17:33:34 +0200 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> Message-ID: On 8/18/07, Colin Walters wrote: > > (or really, any application other than a web browser) > this is simply not true if this was the case many people would have no problem to switch to linux. "I would like to switch but app X or game Y are not available for linux" a regular user want to surf the web, use a word processer, chat using a IM client, listen to music, watch videos and play games. (but this has nothing to do with the the root password). about the root account: I would prefer to just disable the root login in gdm. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rstrode at redhat.com Sat Aug 18 16:14:02 2007 From: rstrode at redhat.com (Ray Strode) Date: Sat, 18 Aug 2007 12:14:02 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> Message-ID: <46C71ACA.4030808@redhat.com> hi, > I would prefer to just disable the root login in gdm. It makes sense to do outside of the desktop livecd spin, too. Root login has never really worked right. For instance, you can't lock your screen. Anyway, building a gdm package into koji now to disable it. --Ray From sundaram at fedoraproject.org Sat Aug 18 16:15:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Aug 2007 21:45:41 +0530 Subject: low-hanging fruit In-Reply-To: <46C71ACA.4030808@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C71ACA.4030808@redhat.com> Message-ID: <46C71B2D.2090001@fedoraproject.org> Ray Strode wrote: > hi, >> I would prefer to just disable the root login in gdm. > It makes sense to do outside of the desktop livecd spin, too. Root > login has never really worked right. For instance, you can't lock your > screen. > > Anyway, building a gdm package into koji now to disable it. Can KDE folks do this for KDM too? Rahul From pemboa at gmail.com Sat Aug 18 17:06:41 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 18 Aug 2007 12:06:41 -0500 Subject: low-hanging fruit In-Reply-To: <46C71B2D.2090001@fedoraproject.org> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C71ACA.4030808@redhat.com> <46C71B2D.2090001@fedoraproject.org> Message-ID: <16de708d0708181006n4e550793g1e3eb5c4902345a0@mail.gmail.com> On 8/18/07, Rahul Sundaram wrote: > Ray Strode wrote: > > hi, > >> I would prefer to just disable the root login in gdm. > > It makes sense to do outside of the desktop livecd spin, too. Root > > login has never really worked right. For instance, you can't lock your > > screen. > > > > Anyway, building a gdm package into koji now to disable it. > > Can KDE folks do this for KDM too? > > Rahul I think KDM has been like this for at least the last two releases. I'm subject to correction. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From rdieter at math.unl.edu Sun Aug 19 14:54:57 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 19 Aug 2007 09:54:57 -0500 Subject: low-hanging fruit References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C71ACA.4030808@redhat.com> <46C71B2D.2090001@fedoraproject.org> <16de708d0708181006n4e550793g1e3eb5c4902345a0@mail.gmail.com> Message-ID: Arthur Pemberton wrote: > On 8/18/07, Rahul Sundaram wrote: >> Ray Strode wrote: >> > hi, >> >> I would prefer to just disable the root login in gdm. >> > It makes sense to do outside of the desktop livecd spin, too. Root >> > login has never really worked right. For instance, you can't lock your >> > screen. >> > >> > Anyway, building a gdm package into koji now to disable it. >> >> Can KDE folks do this for KDM too? > I think KDM has been like this for at least the last two releases. I'm > subject to correction. Releases previous to F7 did that (disabled root login), F7 does not. -- Rex From pemboa at gmail.com Sun Aug 19 17:52:25 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 19 Aug 2007 12:52:25 -0500 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C71ACA.4030808@redhat.com> <46C71B2D.2090001@fedoraproject.org> <16de708d0708181006n4e550793g1e3eb5c4902345a0@mail.gmail.com> Message-ID: <16de708d0708191052g78737879meedb978877ec2aa4@mail.gmail.com> On 8/19/07, Rex Dieter wrote: > Arthur Pemberton wrote: > > > On 8/18/07, Rahul Sundaram wrote: > >> Ray Strode wrote: > >> > hi, > >> >> I would prefer to just disable the root login in gdm. > >> > It makes sense to do outside of the desktop livecd spin, too. Root > >> > login has never really worked right. For instance, you can't lock your > >> > screen. > >> > > >> > Anyway, building a gdm package into koji now to disable it. > >> > >> Can KDE folks do this for KDM too? > > > I think KDM has been like this for at least the last two releases. I'm > > subject to correction. > > Releases previous to F7 did that (disabled root login), F7 does not. > > -- Rex > Interesting. I think it started about FC3? Any reason this was reversed in F7? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From rdieter at math.unl.edu Sun Aug 19 20:51:29 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 19 Aug 2007 15:51:29 -0500 Subject: low-hanging fruit References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C71ACA.4030808@redhat.com> <46C71B2D.2090001@fedoraproject.org> <16de708d0708181006n4e550793g1e3eb5c4902345a0@mail.gmail.com> <16de708d0708191052g78737879meedb978877ec2aa4@mail.gmail.com> Message-ID: Arthur Pemberton wrote: > On 8/19/07, Rex Dieter wrote: >> Arthur Pemberton wrote: >> > I think KDM has been like this for at least the last two releases. I'm >> > subject to correction. >> >> Releases previous to F7 did that (disabled root login), F7 does not. > Interesting. I think it started about FC3? Any reason this was reversed in > F7? I disagreed with it, and (at the time) it was inconsistent with gdm's configuration. -- Rex From kevin.verma at gmail.com Sun Aug 19 22:16:14 2007 From: kevin.verma at gmail.com (Anuj Verma (Kevin)) Date: Sun, 19 Aug 2007 22:16:14 +0000 (UTC) Subject: no epiphany.i386 package for Fedora x86_64 ? Message-ID: Hello, I use epiphany as my default browser of choice instead firefox. This goes well on i386 installs of Fedora but on x86_64 installations this becomes a trouble, if tools like nspluginwrapper are not working fine or if 64bit JRE plugin is not there yet. Fedora for x86_64 has a firefox.i386 package for 32bit compatibility, should epiphany also have epiphany.i386 package in x86_64 repo ? Kevin From mzerqung at 0pointer.de Mon Aug 20 00:07:35 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 20 Aug 2007 02:07:35 +0200 Subject: low-hanging fruit In-Reply-To: <1187314217.26239.34.camel@cookie.hadess.net> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <1187284974.17169.4.camel@localhost.localdomain> <1187287477.2718.31.camel@localhost.localdomain> <1187287835.17169.13.camel@localhost.localdomain> <20070816141730.3356f3c3@mentok.boston.redhat.com> <1187314217.26239.34.camel@cookie.hadess.net> Message-ID: <20070820000735.GA24281@tango.0pointer.de> On Fri, 17.08.07 02:30, Bastien Nocera (bnocera at redhat.com) wrote: > > Anybody for firewall2allow? (: > > Maybe Lennart can fix it too? :) > > Here's an old entry in my bookmarks: > http://0pointer.de/lennart/projects/fieryfilter/ > http://0pointer.de/lennart/projects/fieryfilter/fieryfilter.png > > This probably needs UI love, and use of D-Bus instead of Unix sockets > for the admin rights, but the idea is there. Fieryfilter used the userspace QUEUE netfilter target to do its work. That sucked big time, because if the user didn't click away his dialogs quick enough the sender would repeat its packet which is difficult to deal with if you don't want to accumulate dialogs for the same packets. If someone wants to investigate the whole desktop firewall for Linux thing a little more I think it would make more sense to write an LSM module for that kernel that intercepts the socket calls (i.e, accept(), listen(), connect() and friends) and relays them to userspace for a verdict. Would be much cleaner and simpler. And would also be a good excuse to keep LSM in the kernel. ;-) (Hmm, that could also be integrated with PolicyKit...) Last time I looked it was difficult to stack LSMs, hence this all is not trivial. When you do all that (moving it on the D-Bus, a new UI and basing the work on LSM instead of netfilter) then you would not be able tokeep a single line of code of the old fieryfilter. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From gmureddu at prodigy.net.mx Mon Aug 20 03:30:09 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Sun, 19 Aug 2007 23:30:09 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> Message-ID: <46C90AC1.7050805@prodigy.net.mx> Colin Walters escribi?: > On 8/16/07, *Gian Paolo Mureddu* > wrote: > > > fine, adding sudo by default doesn't seem like very good idea for me, > especially after my experiences with *buntu systems where the whole > */sbin paths are visible to the regular users, > > > But what is a "regular" user? If you have the Vista/OSX desktop spin, > "regular users" won't ever open a terminal (or really, any application > other than a web browser), and so the default path is completely > irrelevant. > > But as a developer, when I open a terminal I want ifconfig, damn it. Then change your .bashrc to include /sbin in the PATH, don't do it "universally" for all users and much less *enforce* insecure practices. Besides as I said, many of the /sbin commands run as regular users, and just like you I don't see the "burden" to use the full path... /sbin/ifconfig... > > and though many of those > commands need proper authentication to do their job, there are quite a > few which can run with regular UIDs. I've always thought that the > presence of a proper 'root' account in Fedora and Red Hat was way > better > than having one "disabled". > > > It's unclear to me how the root account being enabled or not relates > to the path. > > Anyways, I couldn't care less about whether or not you can log in as > "root". What is important is to kill password prompts, *especially* > prompts for two passwords. If we killed the prompt for the updater > we'd be 90% there since that's the only thing that regularly prompts > (or used to) in day to day use. Are we going completely out of our minds here?? Since when alerting the user that s/he's about to do something that will affect the whole system is a bad idea? I do agree that having two password pop ups might not be the best or most elegant solution, but neither is "opening up" the system and putting it at risk. Getting rid of that extra layer *is* putting the system at risk. Especially in the hands of inexperienced users (and I know and am aware that Fedora's traditional audience is *NOT* inexperienced users, and yet, the Forums are flooded with new users questions and issues... So I'd think of them too). > > > This forum thread fixed it for me: > http://forums.fedoraforum.org/archive/index.php/t-139634.html > > Let's just do it. From alexl at redhat.com Mon Aug 20 06:59:52 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 20 Aug 2007 08:59:52 +0200 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <1187021402.2998.12.camel@oneill.fubar.dk> References: <1185920349.12650.4.camel@neutron.verbum.private> <1187021402.2998.12.camel@oneill.fubar.dk> Message-ID: <1187593192.3054.4.camel@localhost.localdomain> On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote: > > Btw, in the same vein, we probably want ~/Public to be created with mode > rwxr-xr-x as well; I believe that requires a patch to xdg-user-dirs such > that the mode can be specified in /etc/xdg/user-dirs.defaults. Longer > term we should probably make ~/Public of other users visible somewhere > and integrate it into the file manager or whatever. Alex? Interesting idea. Seems sane to me. From katzj at redhat.com Mon Aug 20 15:58:31 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Aug 2007 11:58:31 -0400 Subject: low-hanging fruit In-Reply-To: <46C71ACA.4030808@redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C71ACA.4030808@redhat.com> Message-ID: <1187625511.7085.92.camel@localhost.localdomain> On Sat, 2007-08-18 at 12:14 -0400, Ray Strode wrote: > > I would prefer to just disable the root login in gdm. > It makes sense to do outside of the desktop livecd spin, too. Root > login has never really worked right. For instance, you can't lock your > screen. > > Anyway, building a gdm package into koji now to disable it. So if we're going to do this, we also should think a bit about the path how users get created to ensure that people don't end up in a situation where they've installed and only have a root account but end up at gdm. 1) No user got created in firstboot. We tell you that you should and we say "are you sure you want to" if you don't, but it's still quite easy not to 2) User gets text-mode firstboot (which doesn't ask you to create a user). This should only happen if a) you boot into runlevel 3 because of your install b) text mode installs might still imply text mode firstboot c) any other cases? 3) firstboot crashed. Simple answer, firstboot shouldn't crash :-) But maybe not that simple. 4) You set up network logins, but your network isn't working/you're using NetworkManager. Also maybe a "don't do this" type of thing. The first two are the ones that worry me the most. And I guess the third, too. We could be more certain that a user went through and was presented the "create a user" bit if we moved the user creation (back) into anaconda. That doesn't fix the "I chose not to create a user" case, though. So the bigger thing is how do we make it mandatory while still having things moderately reasonable for the users who choose to set up some form of network login[1]. Maybe we just punt and say if you're doing network login only, you're probably using kickstart? And I guess there's nothing which says you can't delete the user after you set up your network login stuff. Jeremy [1] In the past, the concern was if you're doing network logins, you don't want _any_ local accounts to avoid the "local user overrides the network user" problem. From walters at redhat.com Mon Aug 20 16:02:56 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 20 Aug 2007 12:02:56 -0400 Subject: low-hanging fruit In-Reply-To: <46C90AC1.7050805@prodigy.net.mx> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> Message-ID: On 8/19/07, Gian Paolo Mureddu wrote: > > > Then change your .bashrc to include /sbin in the PATH, don't do it > "universally" for all users and much less *enforce* insecure practices. This part isn't an important debate so I'm skipping to the next part. > > Are we going completely out of our minds here?? Since when alerting the > user that s/he's about to do something that will affect the whole system > is a bad idea? I do agree that having two password pop ups might not be > the best or most elegant solution, but neither is "opening up" the > system and putting it at risk. Getting rid of that extra layer *is* > putting the system at risk. Ok, here is where we need to frame the discussion. The scenario I am thinking of is a Fedora spin that is in the "XP/OS X" category. Adding a password prompt of any kind, no less for some other "root" password, *actively harms security*. Why? Because the most important thing you can do for security - THE most important - for a home user desktop is to get them updates reliably and as painlessly as possible. In particular for the web browser. It's completely ironic to me that people are wanting to add password prompts for installing software from GPG-signed Fedora repositories when it's quite possibly the LEAST dangerous thing one could do on a computer. Why don't we have a password prompt before you can start the web browser? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.nettleton at gmail.com Mon Aug 20 16:13:02 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Mon, 20 Aug 2007 12:13:02 -0400 Subject: low-hanging fruit In-Reply-To: <1187625511.7085.92.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C71ACA.4030808@redhat.com> <1187625511.7085.92.camel@localhost.localdomain> Message-ID: On 8/20/07, Jeremy Katz wrote: > > On Sat, 2007-08-18 at 12:14 -0400, Ray Strode wrote: > > > I would prefer to just disable the root login in gdm. > > It makes sense to do outside of the desktop livecd spin, too. Root > > login has never really worked right. For instance, you can't lock your > > screen. > > > > Anyway, building a gdm package into koji now to disable it. > > So if we're going to do this, we also should think a bit about the path > how users get created to ensure that people don't end up in a situation > where they've installed and only have a root account but end up at gdm. > > 1) No user got created in firstboot. We tell you that you should and we > say "are you sure you want to" if you don't, but it's still quite easy > not to > 2) User gets text-mode firstboot (which doesn't ask you to create a > user). This should only happen if a) you boot into runlevel 3 because > of your install b) text mode installs might still imply text mode > firstboot c) any other cases? > 3) firstboot crashed. Simple answer, firstboot shouldn't crash :-) But > maybe not that simple. > 4) You set up network logins, but your network isn't working/you're > using NetworkManager. Also maybe a "don't do this" type of thing. > > The first two are the ones that worry me the most. And I guess the > third, too. We could be more certain that a user went through and was > presented the "create a user" bit if we moved the user creation (back) > into anaconda. > > That doesn't fix the "I chose not to create a user" case, though. So > the bigger thing is how do we make it mandatory while still having > things moderately reasonable for the users who choose to set up some > form of network login[1]. Maybe we just punt and say if you're doing > network login only, you're probably using kickstart? And I guess > there's nothing which says you can't delete the user after you set up > your network login stuff. What if instead of disabling the root account in gdm, we change root's default session. Rather than a feature complete gnome-session, we actually run a fullscreen interface much like firstboot that gives access to common administrator functionality, Setup Network, Add Users, Display config, etc etc. Maybe give access to a terminal as well. Hopefully, this would discourage normal users from just using root, but will give a fall back gui to do super user tasks. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at redhat.com Mon Aug 20 16:19:54 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 20 Aug 2007 12:19:54 -0400 Subject: low-hanging fruit In-Reply-To: <1187625511.7085.92.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C71ACA.4030808@redhat.com> <1187625511.7085.92.camel@localhost.localdomain> Message-ID: On 8/20/07, Jeremy Katz wrote: > > > So if we're going to do this, we also should think a bit about the path > how users get created to ensure that people don't end up in a situation > where they've installed and only have a root account but end up at gdm. Guest account is an approach for this issue: https://hosted.fedoraproject.org/projects/guest-account/ In fact I would just make it the default (with UI fixes, it's not there yet) - no firstboot, you get to GDM, you type in your name (not "username"), and off you go. -------------- next part -------------- An HTML attachment was scrubbed... URL: From caillon at redhat.com Mon Aug 20 16:22:10 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 20 Aug 2007 12:22:10 -0400 Subject: no epiphany.i386 package for Fedora x86_64 ? In-Reply-To: References: Message-ID: <46C9BFB2.2040706@redhat.com> Anuj Verma (Kevin) wrote: > Hello, > > I use epiphany as my default browser of choice instead firefox. This goes > well on i386 installs of Fedora but on x86_64 installations this becomes > a trouble, if tools like nspluginwrapper are not working fine or if 64bit > JRE plugin is not there yet. > > Fedora for x86_64 has a firefox.i386 package for 32bit compatibility, > should epiphany also have epiphany.i386 package in x86_64 repo ? Fedora doesn't have a 32 bit package for compatibility; it's only there because of the way multilib works. If so many apps didn't rely on it to build against, there would be only a 64 bit version. Now that nspluginwrapper is in rawhide though, it should be working no? File a bug if not. From mccann at jhu.edu Mon Aug 20 16:26:02 2007 From: mccann at jhu.edu (William Jon McCann) Date: Mon, 20 Aug 2007 12:26:02 -0400 Subject: low-hanging fruit In-Reply-To: <1187625511.7085.92.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C71ACA.4030808@redhat.com> <1187625511.7085.92.camel@localhost.localdomain> Message-ID: <939dd5750708200926k7c3d0a92of7fabaaca025b5b4@mail.gmail.com> Hi, On 8/20/07, Jeremy Katz wrote: > On Sat, 2007-08-18 at 12:14 -0400, Ray Strode wrote: > > > I would prefer to just disable the root login in gdm. > > It makes sense to do outside of the desktop livecd spin, too. Root > > login has never really worked right. For instance, you can't lock your > > screen. > > > > Anyway, building a gdm package into koji now to disable it. > > So if we're going to do this, we also should think a bit about the path > how users get created to ensure that people don't end up in a situation > where they've installed and only have a root account but end up at gdm. > ... Even bigger picture, you may be able to identify at least different use cases: 1) some things may be done by default 2) nothing may be done by default. One way of thinking about the first case is that it is like when you visit amazon.com. You don't have to login to amazon to look at products. You are basically just a guest and have the default experience. Once you identify yourself you get a customized experience. And it remembers you when you come back or until you click "If you are not Jon then click here." The second case is basically the traditional enterprise deny first scheme that we use now. It may be that outside of institutions the first case is more appropriate. Jon From jkeating at redhat.com Mon Aug 20 16:35:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Aug 2007 12:35:36 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> Message-ID: <20070820123536.6d1ff920@mentok.boston.redhat.com> On Mon, 20 Aug 2007 12:02:56 -0400 "Colin Walters" wrote: > Ok, here is where we need to frame the discussion. The scenario I am > thinking of is a Fedora spin that is in the "XP/OS X" category. Not really helpful here, but OS X does prompt you for your password when installing updates. Presumably so that they can do some sudo action behind the scenes to apply said updates. I'm comfortable with this, especially if we go down the road of adding the first user to sudo at install time. Does gnome-keyring have a sensible timeout? If I left my workstation for a period of time and forgot to enable the screensaver, can anybody access my keyring contents, or cause something to be authenticated via my keyring? -- 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 katzj at redhat.com Mon Aug 20 16:36:35 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Aug 2007 12:36:35 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C71ACA.4030808@redhat.com> <1187625511.7085.92.camel@localhost.localdomain> Message-ID: <1187627795.7085.98.camel@localhost.localdomain> On Mon, 2007-08-20 at 12:13 -0400, Jon Nettleton wrote: > What if instead of disabling the root account in gdm, we change root's > default session. Rather than a feature complete gnome-session, we > actually run a fullscreen interface much like firstboot that gives > access to common administrator functionality, Setup Network, Add > Users, Display config, etc etc. Maybe give access to a terminal as > well. > > Hopefully, this would discourage normal users from just using root, > but will give a fall back gui to do super user tasks. I think this would be really cool as a way of providing some "save myself" types of things. Jeremy From walters at redhat.com Mon Aug 20 17:26:35 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 20 Aug 2007 13:26:35 -0400 Subject: low-hanging fruit In-Reply-To: <20070820123536.6d1ff920@mentok.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> Message-ID: On 8/20/07, Jesse Keating wrote: > > On Mon, 20 Aug 2007 12:02:56 -0400 > "Colin Walters" wrote: > > > Ok, here is where we need to frame the discussion. The scenario I am > > thinking of is a Fedora spin that is in the "XP/OS X" category. > > Not really helpful here, but OS X does prompt you for your password > when installing updates. Presumably so that they can do some sudo > action behind the scenes to apply said updates. I'm comfortable with > this, especially if we go down the road of adding the first user to > sudo at install time. That is interesting; I honestly haven't used OS X at all. Does OS X also have a password on your account by default, or did you have to explicitly set one? Does gnome-keyring have a sensible timeout? If I left my workstation > for a period of time and forgot to enable the screensaver, can anybody > access my keyring contents, or cause something to be authenticated via > my keyring? Unrelated but - in my opinion gnome-keyring adds very little in terms of security to this scenario. wget http://my.favorite.keylogger.example.com/linux-x86.tgz && tar xzvf *.tgz && sh keylogger/install.sh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Mon Aug 20 17:48:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Aug 2007 13:48:29 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> Message-ID: <20070820134829.15add98e@mentok.boston.redhat.com> On Mon, 20 Aug 2007 13:26:35 -0400 "Colin Walters" wrote: > That is interesting; I honestly haven't used OS X at all. Does OS X > also have a password on your account by default, or did you have to > explicitly set one? That part is a bit fuzzy, but yes, I do believe when I created the user I had to supply a password, and confirm it. It may allow login without password, but it would still prompt for the password whenever you needed to do something "systemy". > Does gnome-keyring have a sensible timeout? If I left my workstation > > for a period of time and forgot to enable the screensaver, can > > anybody access my keyring contents, or cause something to be > > authenticated via my keyring? > > > Unrelated but - in my opinion gnome-keyring adds very little in terms > of security to this scenario. > > wget http://my.favorite.keylogger.example.com/linux-x86.tgz && tar > xzvf *.tgz && sh keylogger/install.sh This was just more a general question. OS X has a timeout on that password prompt I think (or else they just ask it every time for every new app). I was thinking of how gnome-keyring could be used to manage these prompts, but not if it is once unlocked always unlocked. -- 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 davidz at redhat.com Mon Aug 20 18:09:00 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 20 Aug 2007 14:09:00 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> Message-ID: <1187633340.4665.11.camel@oneill.fubar.dk> Hey, Ugh, it would be nice if your mail client broke lines properly; it's at least a mess for me when using Evolution. On Mon, 2007-08-20 at 13:26 -0400, Colin Walters wrote: > Unrelated but - in my opinion gnome-keyring adds > very little in terms of security to this scenario. > > wget http://my.favorite.keylogger.example.com/linux-x86.tgz && \ > tar xzvf *.tgz && sh keylogger/install.sh Two things - It's a fair goal to ensure that users don't have to enter any passwords and I think gnome-keyring and other password stores (like the one in Firefox) helps with that. Especially if it's automatically unlocked when you log in. It's also pretty damn convenient that I don't have to type in these passwords all the time. Plus I can rest assured that if my laptop is stolen, some of my passwords are encrypted (ask blizzard about getting his laptop stolen). FWIW, I consider it a bug that the password store in e.g. Firefox isn't locked the same way we lock gnome-keyring; I know the option in Firefox is there but we just uncheck it by default so you get plaintext passwords. (Of course another solution to the "unlock keyring" problem is just to use encrypted home directories) - It's just a bug [1] that an unprivileged process like your keylogger can grab key presses while the gnome keyring password dialog is focused. With things like XACE, we can prevent that and only allow privileged applications like e.g. a screen reader / on screen keyboard to do this. Of course you can now turn this into a discussion about trusted path. David [1] : or misfeature, whatever From walters at redhat.com Mon Aug 20 18:28:20 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 20 Aug 2007 14:28:20 -0400 Subject: low-hanging fruit In-Reply-To: <1187633340.4665.11.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> Message-ID: On 8/20/07, David Zeuthen wrote: > > > - It's a fair goal to ensure that users don't have to enter any > passwords and I think gnome-keyring and other password stores (like > the one in Firefox) helps with that. Especially if it's automatically > unlocked when you log in. For sure I agree the API-to-store-stuff aspect of the keyring is good, because in theory it lets you share stuff between applications. In practice that seems to have mostly failed. Pidgin and Firefox do their own thing, and almost everything I see that actually uses gnome-keyring uses the GENERIC_SECRET instead of NETWORK_PASSWORD so you can't easily reuse logins between apps...at least not without getting stormed by "Allow or Deny?". It's also pretty damn convenient that I don't have to type in these > passwords all the time. Plus I can rest assured that if my laptop > is stolen, some of my passwords are encrypted (ask blizzard about > getting his laptop stolen). See below... FWIW, I consider it a bug that the password store in e.g. Firefox > isn't locked the same way we lock gnome-keyring; I know the option > in Firefox is there but we just uncheck it by default so you get > plaintext passwords. Well they're not directly plaintext on disk (I actually looked at this as part of killing-login-dialogs thing); but yeah the key used to decrypt them is right there so it ends up being more a CVS-style rot13 obfuscation (which is a good idea). (Of course another solution to the "unlock keyring" problem is just > to use encrypted home directories) Right; this is the real solution to the stolen-laptop problem and I'm all for it! - It's just a bug [1] that an unprivileged process like your keylogger > can grab key presses while the gnome keyring password dialog is > focused. With things like XACE, we can prevent that and only allow > privileged applications like e.g. a screen reader / on screen > keyboard to do this. > > Of course you can now turn this into a discussion about trusted path. Right =) The guiding principle here being: If someone has physical access to your computer and hostile intent, you've already lost. Not that it's impossible to defend against but...it gets increasingly baroque and the important thing to secure is the web browser. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Mon Aug 20 18:40:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Aug 2007 14:40:52 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> Message-ID: <20070820144052.2a5c708b@mentok.boston.redhat.com> On Mon, 20 Aug 2007 14:28:20 -0400 "Colin Walters" wrote: > Right; this is the real solution to the stolen-laptop problem and I'm > all for it! Except if your session was logged in when it got stolen (seen those commercials about the pretty girl in the coffee shop? (: ). This is why I want some sort of session timeout (other than the screensaver) on how long these things sit unlocked for you to access them. -- 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 bill at pecknet.com Mon Aug 20 18:53:31 2007 From: bill at pecknet.com (Bill Peck) Date: Mon, 20 Aug 2007 14:53:31 -0400 Subject: low-hanging fruit In-Reply-To: <20070820144052.2a5c708b@mentok.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <20070820144052.2a5c708b@mentok.boston.redhat.com> Message-ID: On 8/20/07, Jesse Keating wrote: > On Mon, 20 Aug 2007 14:28:20 -0400 > "Colin Walters" wrote: > > > Right; this is the real solution to the stolen-laptop problem and I'm > > all for it! > > Except if your session was logged in when it got stolen (seen those > commercials about the pretty girl in the coffee shop? (: ). This is > why I want some sort of session timeout (other than the screensaver) on > how long these things sit unlocked for you to access them. RFID ring that you wear ;-) When your ring is out of range for the laptop to read it locks your gnome keyring. ;-) ok.. so it doesn't help if you don't have the ring or a laptop which can read rfid.. darn. > > -- > Jesse Keating > Fedora -- All my bits are free, are yours? > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > > From walters at redhat.com Mon Aug 20 18:55:29 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 20 Aug 2007 14:55:29 -0400 Subject: low-hanging fruit In-Reply-To: <20070820144052.2a5c708b@mentok.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <20070820144052.2a5c708b@mentok.boston.redhat.com> Message-ID: On 8/20/07, Jesse Keating wrote: > > On Mon, 20 Aug 2007 14:28:20 -0400 > "Colin Walters" wrote: > > > Right; this is the real solution to the stolen-laptop problem and I'm > > all for it! > > Except if your session was logged in Right, we should design for this because we're moving towards having an always logged in session: http://blogs.gnome.org/halfline/2007/07/25/screensaver-extension/ Which just makes sense because why would you ever log out? Generally you either suspend or switch users. when it got stolen (seen those > commercials about the pretty girl in the coffee shop? (: ). This is > why I want some sort of session timeout (other than the screensaver) on > how long these things sit unlocked for you to access them. Hm. So we have right now three "I'm leaving the computer" buttons. One called "Suspend", one called "Hibernate", and one called "Lock Screen". Differentiating between the first two is an unrelated bug, so that leaves us with Suspend and Lock screen. Why not just suspend (and save lots of power), and on un-suspend, you display the password prompt? Then you can change things so that if the system doesn't get a password response from unsuspend within say 2-3 minutes it shuts down, leaving all the /home or / or whatever encrypted with nothing running. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidz at redhat.com Mon Aug 20 18:55:48 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 20 Aug 2007 14:55:48 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> Message-ID: <1187636148.4665.31.camel@oneill.fubar.dk> Hi, On Mon, 2007-08-20 at 14:28 -0400, Colin Walters wrote: > On 8/20/07, David Zeuthen wrote: > > - It's a fair goal to ensure that users don't have to enter > any > passwords and I think gnome-keyring and other password > stores (like > the one in Firefox) helps with that. Especially if it's > automatically > unlocked when you log in. > > For sure I agree the API-to-store-stuff aspect of the keyring is good, > because in theory it lets you share stuff between applications. In > practice that seems to have mostly failed. Pidgin and Firefox do > their own thing, and almost everything I see that actually uses > gnome-keyring uses the GENERIC_SECRET instead of NETWORK_PASSWORD so > you can't easily reuse logins between apps...at least not without > getting stormed by "Allow or Deny?". I think one point here is that only Evolution can read my IMAP password; only pidgin can read my instant messenger passwords and so forth. The whole "Allow or Deny?" thing, I think, is a bit misguided and just opens up another avenue of attacks. Shrug. > FWIW, I consider it a bug that the password store in e.g. > Firefox > isn't locked the same way we lock gnome-keyring; I know the > option > in Firefox is there but we just uncheck it by default so > you get > plaintext passwords. > > Well they're not directly plaintext on disk (I actually looked at this > as part of killing-login-dialogs thing); but yeah the key used to > decrypt them is right there so it ends up being more a CVS-style rot13 > obfuscation (which is a good idea). Yeah, as I said; they're stored in plaintext :-) > Right; this is the real solution to the stolen-laptop problem and I'm > all for it! Except that it doesn't address one serious problem... > Right =) The guiding principle here being: If someone has > physical access to your computer and hostile intent, you've > already lost. (Sure, and with physical access why even bother with installing *software* when you can easily attach a cheap wireless camera pointing at the keyboard or a hardware keylogger attached the USB or PS2 keyboard cable.) > Not that it's impossible to defend against but...it gets increasingly > baroque and the important thing to secure is the web browser. The serious problem here is that with the way people use the Internet there will always be plenty of attack vectors; you mention the web browser, there's a bunch of other well known vectors - PDF viewers - Image viewers - AV Codecs - IM clients - VM's like Flash, Silverlight/Moonlight, Java - Random apps downloaded off the Internet Note that there will be *more* of these every singe day simply because people use the Internet in more interesting ways. And then there's all the social engineering attacks. So, like it or not, we simply need to engineer the security of the operating system such that untrusted code running in your desktop session can do as little harm as possible. This includes making sure that such harmful software - Can't elevate itself; either through code exploits - ... or by bringing up auth / acknowledge dialogs that look like system auth dialogs - Can't spy on you (event snooping) / do things on your behalf - Can't access secrets; e.g. it's a non-starter to have your Firefox password database accessible to any app running with your uid. It's just not enough to obfuscate it. Ditto for your mail client / IM client and so forth. It's quite a challenge, I think, how to do this properly in a world where we increasingly want applications to feel integrated. Either that, or we say "we've lost" if untrusted code is running in your session. David From jon.nettleton at gmail.com Mon Aug 20 19:01:44 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Mon, 20 Aug 2007 15:01:44 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <20070820144052.2a5c708b@mentok.boston.redhat.com> Message-ID: On 8/20/07, Bill Peck wrote: > > On 8/20/07, Jesse Keating wrote: > > On Mon, 20 Aug 2007 14:28:20 -0400 > > "Colin Walters" wrote: > > > > > Right; this is the real solution to the stolen-laptop problem and I'm > > > all for it! > > > > Except if your session was logged in when it got stolen (seen those > > commercials about the pretty girl in the coffee shop? (: ). This is > > why I want some sort of session timeout (other than the screensaver) on > > how long these things sit unlocked for you to access them. > > RFID ring that you wear ;-) When your ring is out of range for the > laptop to read it locks your gnome keyring. ;-) > > ok.. so it doesn't help if you don't have the ring or a laptop which > can read rfid.. darn. Was playing with this over the weekend. http://blueproximity.sourceforge.net/ Not uber secure being based on bluetooth, but a neat concept. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Mon Aug 20 19:02:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Aug 2007 15:02:14 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <20070820144052.2a5c708b@mentok.boston.redhat.com> Message-ID: <20070820150214.5da68e9f@mentok.boston.redhat.com> On Mon, 20 Aug 2007 14:55:29 -0400 "Colin Walters" wrote: > Hm. So we have right now three "I'm leaving the computer" buttons. > One called "Suspend", one called "Hibernate", and one called "Lock > Screen". Differentiating between the first two is an unrelated bug, > so that leaves us with Suspend and Lock screen. Why not just suspend > (and save lots of power), and on un-suspend, you display the password > prompt? > > Then you can change things so that if the system doesn't get a > password response from unsuspend within say 2-3 minutes it shuts > down, leaving all the /home or / or whatever encrypted with nothing > running. That might be doable for the coming back from suspend case. I don't suspend when walking away because I don't want my wireless to drop, I don't want to have to re-login to say t-mobile hot-spot, I don't want to dance my little dance with apps thinking "Oh! NM is reconnected, I can re-establish all my connections again" when the vpn isn't ready yet, or t-mobile hasn't let me to the real Internet yet so I have to fix all the 'connection lost' or wait for stupid ass timeouts to return. Relying on a lock screen is fine, but we still make that optional. We should timeout the keyrings no matter what after a period of inactivity. If they're re-unlocked via a locked screen unlock great, otherwise throw up a "Session timeout" passphrase box before allowing anything else to happen. (maybe I'm too far off in the weeds...) -- 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 davidz at redhat.com Mon Aug 20 19:02:37 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 20 Aug 2007 15:02:37 -0400 Subject: low-hanging fruit In-Reply-To: <20070820144052.2a5c708b@mentok.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <20070820144052.2a5c708b@mentok.boston.redhat.com> Message-ID: <1187636557.4665.36.camel@oneill.fubar.dk> On Mon, 2007-08-20 at 14:40 -0400, Jesse Keating wrote: > On Mon, 20 Aug 2007 14:28:20 -0400 > "Colin Walters" wrote: > > > Right; this is the real solution to the stolen-laptop problem and I'm > > all for it! > > Except if your session was logged in when it got stolen (seen those > commercials about the pretty girl in the coffee shop? (: ). This is > why I want some sort of session timeout (other than the screensaver) on > how long these things sit unlocked for you to access them. FWIW, for the first few weeks in Rawhide after F7 IIRC, gnome-power-manager used to lock your keyring when resuming after suspend. Most people *hated* it. I think you can still turn it on via gconf however, yup, it's /apps/gnome-power-manager/lock/gnome_keyring_hibernate /apps/gnome-power-manager/lock/gnome_keyring_suspend with the explanation Whether the GNOME keyring is locked before the computer enters suspend. This means the the keyring will have to be unlocked on resume. Personally, I thought it was a horrible feature. David From walters at redhat.com Mon Aug 20 19:08:39 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 20 Aug 2007 15:08:39 -0400 Subject: low-hanging fruit In-Reply-To: <1187636148.4665.31.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> Message-ID: On 8/20/07, David Zeuthen wrote: > > > So, like it or not, we simply need to engineer the security of the > operating system such that untrusted code running in your desktop > session can do as little harm as possible. Ok we're pretty far afield here but I don't disagree with anything you're saying here - all that work would help - but it doesn't change my opinion that by far the biggest bang for the buck in terms of security is making sure we get updates as painlessly (well tested etc.) as possible. And hence, that's why we should not have any password prompts for updating. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Mon Aug 20 19:11:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Aug 2007 15:11:44 -0400 Subject: low-hanging fruit In-Reply-To: <1187636557.4665.36.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <20070820144052.2a5c708b@mentok.boston.redhat.com> <1187636557.4665.36.camel@oneill.fubar.dk> Message-ID: <20070820151144.0a0f3eda@mentok.boston.redhat.com> On Mon, 20 Aug 2007 15:02:37 -0400 David Zeuthen wrote: > FWIW, for the first few weeks in Rawhide after F7 IIRC, > gnome-power-manager used to lock your keyring when resuming after > suspend. Most people *hated* it. I think you can still turn it on via > gconf however, yup, it's > > /apps/gnome-power-manager/lock/gnome_keyring_hibernate > /apps/gnome-power-manager/lock/gnome_keyring_suspend > > with the explanation > > Whether the GNOME keyring is locked before the computer enters > suspend. This means the the keyring will have to be unlocked on > resume. > > Personally, I thought it was a horrible feature. I'm OK with it being locked, if the unlocking the screen saver also unlocks the keyring, and if there is no screen saver that we timeout the keyring anyway without activity. It would be just like sudo, which if you haven't entered your passphrase in a while you get prompted for it again. -- 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 walters at redhat.com Mon Aug 20 19:18:56 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 20 Aug 2007 15:18:56 -0400 Subject: low-hanging fruit In-Reply-To: <20070820150214.5da68e9f@mentok.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <20070820144052.2a5c708b@mentok.boston.redhat.com> <20070820150214.5da68e9f@mentok.boston.redhat.com> Message-ID: On 8/20/07, Jesse Keating wrote: > > > I don't suspend when walking away because I don't want my wireless to > drop, I don't want to have to re-login to say t-mobile hot-spot, Yeah, sigh...these wifi browser prompts completely destroy the user experience for so many applications. My personal favorite is starting Firefox, clicking "Resume session" and getting 15 redirected login tabs. Long term I hope we can figure out some way to make that suck less. I don't have any good ideas right now about how to detect the situation initially. That said though, maybe if we only suspend for say the time it takes to go to the bathroom (~2 minutes) it might not toss you back at that prompt. I'm not sure how that works - if it authorizes your MAC address for X minutes or whether it's "DHCP request implies prompt". In the latter case we might be able to fix NetworkManager to save its DHCP lease if it's within the lease time still and not do another request on unsuspend if it's the same network. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Mon Aug 20 19:24:56 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 20 Aug 2007 15:24:56 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <20070820144052.2a5c708b@mentok.boston.redhat.com> Message-ID: <1187637896.16948.17.camel@cutter> On Mon, 2007-08-20 at 14:55 -0400, Colin Walters wrote: > > Right, we should design for this because we're moving towards having > an always logged in session: > http://blogs.gnome.org/halfline/2007/07/25/screensaver-extension/ > Which just makes sense because why would you ever log out? Generally > you either suspend or switch users. okay - so I understand that this is targeted for laptops and home machines - but for people running fedora and/or rhel in a lab/classroom this won't fly at all. Having 2 or 3 people logged in and switched is fine. Having 500-1000 switched out won't work very well at all. So - this needs to be an option about the always-logged-in-sessions. -sv From davidz at redhat.com Mon Aug 20 19:22:43 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 20 Aug 2007 15:22:43 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> Message-ID: <1187637763.4665.47.camel@oneill.fubar.dk> On Mon, 2007-08-20 at 15:08 -0400, Colin Walters wrote: > On 8/20/07, David Zeuthen wrote: > > So, like it or not, we simply need to engineer the security of > the > operating system such that untrusted code running in your > desktop > session can do as little harm as possible. > > Ok we're pretty far afield here but I don't disagree with anything > you're saying here - all that work would help - but it doesn't change > my opinion that by far the biggest bang for the buck in terms of > security is making sure we get updates as painlessly (well tested > etc.) as possible. And hence, that's why we should not have any > password prompts for updating. Oh, I think we definitely agree on that. Btw, with the work on PolicyKit that I'm doing http://people.freedesktop.org/~david/polkit-admin-auth-1.png combined with the PackageKit work Richard is doing http://hughsient.livejournal.com/32948.html we should be close, with a bit of luck anyway, to having something for Fedora 9. I'm hoping to find time in a month or two to help out on that. Anyway, the beauty of this is that for the Fedora desktop spin we'll just ship with a /etc/PolicyKit/PolicyKit.conf [1] file that allows the action (and others) of updating the OS with signed package without asking for auth. And the admin (if any) can always change this however he likes. For a hypothetical super-secure govt compliant locked-down and secure desktop spin it will always default to denying this (and other actions) without even asking for any passwords. Centralized, fine grained, secure. David [1] : http://gitweb.freedesktop.org/?p=PolicyKit.git;a=blob;hb=HEAD;f=doc/man/PolicyKit.conf.5.in > From mzerqung at 0pointer.de Mon Aug 20 20:10:51 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 20 Aug 2007 22:10:51 +0200 Subject: PA by default In-Reply-To: <1187301234.26239.30.camel@cookie.hadess.net> References: <1187301234.26239.30.camel@cookie.hadess.net> Message-ID: <20070820201051.GH25276@tango.0pointer.de> On Thu, 16.08.07 22:53, Bastien Nocera (bnocera at redhat.com) wrote: > Heya, > > Before Fedora 8, is there a plan to fix a few regressions or integration > issue with PA? > > From: > https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01196.html > > > You also have to make sure that some GConf keys are set up properly: > > > > /system/gstreamer/0.10/default/audiosrc -> pulsesrc > > /system/gstreamer/0.10/default/audiosink -> pulsesink (or autoaudiosink) > > /system/gstreamer/0.10/default/chataudiosink -> pulsesink (or autoaudiosink) > > /system/gstreamer/0.10/default/musicaudiosink -> pulsesink (or autoaudiosink) > > This means that the "Devices" part of the Sound Preferences in GNOME is > pretty useless. I guess there's a PA specific way of changing the > default input and output, but you lose integration with the desktop. Hmm, this capplet somhow vanished completely on my Fedora system. Anyone knows where I can find it? GStreamer supports all kinds of interfaces to enumerate sound devices. gst-pulse supports those. Hence the dialog should work, but I cannot really say since I haven't testes this. (see above) qThe gnome-volume-control device selection does work the last time I looked. > This will also probably break the device selection that the volume > applet uses (it uses the same as the default sound events device, > iirc). Presumable the applet uses the same interfaces as gnome-volume-control and thus should work. A quick check seems to prove that. > I'm also thinking of applications' volume setup. At least Totem and > Rhythmbox have the concept of "system volume" (which is per device, and > they don't touch), and the "application volume" (which they do). Here, > we're adding the "PA volume". The "application volume" and the "PA volume" should be "merged". (see below) > How do we plan on handling that? Volume control is a very difficult topic. It had a couple of discussions with a couple of people how we should expose this best. (Takashi, Kay, thanks!) One has to consider that usually people don't expect that there is a whole series of volume controls one after the other: software volume control in rhythmbox, then a software volume control in PA, the hardware volume control of the WAVE control in ALSA, then the MASTER control in ALSA and finally (if you have a thinkpad at least like I do) another hw amplifier. That's five controls in a row. (let alone the external controls of your active loudspeakers or your hifi system, which we will ignore here for now). FIVE! That's about three and a half too many, I would say. And these are five that you might accidentaly have set to -Inf dB, and which might be the reason why your sound doesn't work. If you look how Apple does volume control in MacOSX (Apple usually does these things right, so it's where we should belook), they have exactly two. One per-app in sw and a one global in hw. Some people might still find this confusing, i.e. one too many, but on the other hand per-app volume control is deadly sexy. So, what I would like to see implemented is this: ALSA hides away unncessary volume controls and initializes them to sane defaults (i.e. "0 dB"), and makes sure there is always a "Master" volume control which is the actual control for the amplification in HW. This is what Takashi has started to work on. PA already exposes this single per-device volume control, and ignores all the rest the hw might expose. That's volume control #1, the per-device hw-based one. For volume #2, the per-stream sw-based one: the PA per-stream volume and the volume adjustment done in GST should be "merged". PA has all the necessary APIs but Gstreamer needs some non-trivial changes for this. Right now GST's mixer control is awful and designed with per-device controls in mind and hardware backends. Hence I am unable to expose the PA per-stream volume properly in gst-pulse. I brought this up to some GST people a while back, but I guess everyone was just too busy and PA was not yet installed by default on Fedora and hence not important enough. Ideally, Rhythmbox should only show the per-stream volume control. If you right click on it a popup menu should open to replace the widget by the hw per-device volume control. Another option of that popup should be to start the volume control tool. Right now we are in the very unfortunate situation to have two volume control tools. One being "pavucontrol" which uses PA and exposes a lot of fun functionality but looks ... shitty -- because I wrote it. And the other one being gnome-volume-control which looks much better but exposes all those unnecessary mixer tracks and doesn't know anything about per-stream volumes. This situation needs some real fixing. I am hoping that eventually someone eventually will pick up this mess and try to find a good solution. (i.e. maybe beef up the gst volume control stuff to new levels, or give my PA UI tools some serious love) Anyone? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From bnocera at redhat.com Mon Aug 20 20:37:25 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 20 Aug 2007 21:37:25 +0100 Subject: PA by default In-Reply-To: <20070820201051.GH25276@tango.0pointer.de> References: <1187301234.26239.30.camel@cookie.hadess.net> <20070820201051.GH25276@tango.0pointer.de> Message-ID: <1187642245.3208.32.camel@cookie.hadess.net> On Mon, 2007-08-20 at 22:10 +0200, Lennart Poettering wrote: > On Thu, 16.08.07 22:53, Bastien Nocera (bnocera at redhat.com) wrote: > > > Heya, > > > > Before Fedora 8, is there a plan to fix a few regressions or integration > > issue with PA? > > > > From: > > https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01196.html > > > > > You also have to make sure that some GConf keys are set up properly: > > > > > > /system/gstreamer/0.10/default/audiosrc -> pulsesrc > > > /system/gstreamer/0.10/default/audiosink -> pulsesink (or autoaudiosink) > > > /system/gstreamer/0.10/default/chataudiosink -> pulsesink (or autoaudiosink) > > > /system/gstreamer/0.10/default/musicaudiosink -> pulsesink (or autoaudiosink) > > > > This means that the "Devices" part of the Sound Preferences in GNOME is > > pretty useless. I guess there's a PA specific way of changing the > > default input and output, but you lose integration with the desktop. > > Hmm, this capplet somhow vanished completely on my Fedora > system. Anyone knows where I can find it? > > GStreamer supports all kinds of interfaces to enumerate sound > devices. gst-pulse supports those. Hence the dialog should work, but I > cannot really say since I haven't testes this. (see above) qThe > gnome-volume-control device selection does work the last time I > looked. gstreamer-sound-properties. It's the "Sound" preference. BTW, do you want me to change the default sinks in gstreamer-plugins-good? If so, could you file a bug so I don't forget :) > > This will also probably break the device selection that the volume > > applet uses (it uses the same as the default sound events device, > > iirc). > > Presumable the applet uses the same interfaces as gnome-volume-control > and thus should work. A quick check seems to prove that. Good. > > I'm also thinking of applications' volume setup. At least Totem and > > Rhythmbox have the concept of "system volume" (which is per device, and > > they don't touch), and the "application volume" (which they do). Here, > > we're adding the "PA volume". > > The "application volume" and the "PA volume" should be "merged". (see > below) Sounds good, but that would mean different code. > > How do we plan on handling that? > > Volume control is a very difficult topic. It had a couple of > discussions with a couple of people how we should expose this > best. (Takashi, Kay, thanks!) One has to consider that usually people > don't expect that there is a whole series of volume controls one after > the other: software volume control in rhythmbox, then a software > volume control in PA, the hardware volume control of the WAVE control > in ALSA, then the MASTER control in ALSA and finally (if you have a > thinkpad at least like I do) another hw amplifier. That's five > controls in a row. (let alone the external controls of your active > loudspeakers or your hifi system, which we will ignore here for > now). FIVE! That's about three and a half too many, I would say. And > these are five that you might accidentaly have set to -Inf dB, and > which might be the reason why your sound doesn't work. Nod. You thought of many more volume controls than I did, and 3's already too many for me :) > If you look how Apple does volume control in MacOSX (Apple usually > does these things right, so it's where we should belook), they have > exactly two. One per-app in sw and a one global in hw. Some people > might still find this confusing, i.e. one too many, but on the other > hand per-app volume control is deadly sexy. It's very useful to have both though. > So, what I would like to see implemented is this: ALSA hides away > unncessary volume controls and initializes them to sane defaults > (i.e. "0 dB"), and makes sure there is always a "Master" volume > control which is the actual control for the amplification in HW. This > is what Takashi has started to work on. PA already exposes this single > per-device volume control, and ignores all the rest the hw might > expose. That's volume control #1, the per-device hw-based one. > > For volume #2, the per-stream sw-based one: the PA per-stream volume > and the volume adjustment done in GST should be "merged". PA has all > the necessary APIs but Gstreamer needs some non-trivial changes for > this. Right now GST's mixer control is awful and designed with > per-device controls in mind and hardware backends. Hence I am unable > to expose the PA per-stream volume properly in gst-pulse. Right now, Totem and Rhythmbox have their own software-volume in the pipelines. Handling the "hardware" mixer that PA shows means that Totem and Rhythmbox would need to special-case PA. > I brought this up to some GST people a while back, but I guess > everyone was just too busy and PA was not yet installed by default on > Fedora and hence not important enough. > > Ideally, Rhythmbox should only show the per-stream volume control. If > you right click on it a popup menu should open to replace the widget > by the hw per-device volume control. Another option of that popup > should be to start the volume control tool. > > Right now we are in the very unfortunate situation to have two volume > control tools. One being "pavucontrol" which uses PA and exposes a lot > of fun functionality but looks ... shitty -- because I wrote it. And > the other one being gnome-volume-control which looks much better but > exposes all those unnecessary mixer tracks and doesn't know anything > about per-stream volumes. This situation needs some real fixing. I am > hoping that eventually someone eventually will pick up this mess and > try to find a good solution. (i.e. maybe beef up the gst volume > control stuff to new levels, or give my PA UI tools some serious love) > Anyone? Huh. I'm not volunteering yet :) From mzerqung at 0pointer.de Mon Aug 20 21:01:50 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 20 Aug 2007 23:01:50 +0200 Subject: PA by default In-Reply-To: <1187642245.3208.32.camel@cookie.hadess.net> References: <1187301234.26239.30.camel@cookie.hadess.net> <20070820201051.GH25276@tango.0pointer.de> <1187642245.3208.32.camel@cookie.hadess.net> Message-ID: <20070820210150.GB28560@tango.0pointer.de> On Mon, 20.08.07 21:37, Bastien Nocera (bnocera at redhat.com) wrote: > > GStreamer supports all kinds of interfaces to enumerate sound > > devices. gst-pulse supports those. Hence the dialog should work, but I > > cannot really say since I haven't testes this. (see above) qThe > > gnome-volume-control device selection does work the last time I > > looked. > > gstreamer-sound-properties. It's the "Sound" preference. Hmm, is not installed on my machine, only gstreamer-properties which is not what I am looking for. Hmm, Google doesn't even find any mention of "gstreamer-sound-properties". Hmm, you probably meant gnome-sound-properties. And update of control-center brought it back now. seems to work fine, too. > BTW, do you want me to change the default sinks in > gstreamer-plugins-good? If so, could you file a bug so I don't > forget :) I checked those and they point to "autoaudiosink" by default, which should be enough to get gst-pulse working by default. And is the best choice anyway, to make sure that people who think that PA is devil's work don't get pissed off needlessly. ;-) > > So, what I would like to see implemented is this: ALSA hides away > > unncessary volume controls and initializes them to sane defaults > > (i.e. "0 dB"), and makes sure there is always a "Master" volume > > control which is the actual control for the amplification in HW. This > > is what Takashi has started to work on. PA already exposes this single > > per-device volume control, and ignores all the rest the hw might > > expose. That's volume control #1, the per-device hw-based one. > > > > For volume #2, the per-stream sw-based one: the PA per-stream volume > > and the volume adjustment done in GST should be "merged". PA has all > > the necessary APIs but Gstreamer needs some non-trivial changes for > > this. Right now GST's mixer control is awful and designed with > > per-device controls in mind and hardware backends. Hence I am unable > > to expose the PA per-stream volume properly in gst-pulse. > > Right now, Totem and Rhythmbox have their own software-volume in the > pipelines. Handling the "hardware" mixer that PA shows means that Totem > and Rhythmbox would need to special-case PA. What I would like to see is that gst-pulse would expose a new interface on the GstPulseSink element that allows you to modify the per-stream volume control. In a way the current volume control abstraction in gst is already designed to work like that, but it's for per-device controls and totall fucked up anyway. So, Totem should check wether the output sink implements this new special interface. And if so it should expose it in the UI. If not, it should add the software volume control thing to the pipeline (which ideally would expose the same aforementioned interface) and use that instead. Looks relatively easy to me, doesn't it? If someone gets this new interface into GST I am happy to add support for it in PA. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From bnocera at redhat.com Mon Aug 20 21:18:26 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 20 Aug 2007 22:18:26 +0100 Subject: PA by default In-Reply-To: <20070820210150.GB28560@tango.0pointer.de> References: <1187301234.26239.30.camel@cookie.hadess.net> <20070820201051.GH25276@tango.0pointer.de> <1187642245.3208.32.camel@cookie.hadess.net> <20070820210150.GB28560@tango.0pointer.de> Message-ID: <1187644706.3208.51.camel@cookie.hadess.net> On Mon, 2007-08-20 at 23:01 +0200, Lennart Poettering wrote: > On Mon, 20.08.07 21:37, Bastien Nocera (bnocera at redhat.com) wrote: > > > > GStreamer supports all kinds of interfaces to enumerate sound > > > devices. gst-pulse supports those. Hence the dialog should work, but I > > > cannot really say since I haven't testes this. (see above) qThe > > > gnome-volume-control device selection does work the last time I > > > looked. > > > > gstreamer-sound-properties. It's the "Sound" preference. > > Hmm, is not installed on my machine, only gstreamer-properties which > is not what I am looking for. Hmm, Google doesn't even find any > mention of "gstreamer-sound-properties". > > Hmm, you probably meant gnome-sound-properties. And update of > control-center brought it back now. seems to work fine, too. Yeah, I'm doing too many things at the same time :) > > BTW, do you want me to change the default sinks in > > gstreamer-plugins-good? If so, could you file a bug so I don't > > forget :) > > I checked those and they point to "autoaudiosink" by default, which > should be enough to get gst-pulse working by default. And is the best > choice anyway, to make sure that people who think that PA is devil's > work don't get pissed off needlessly. ;-) If that makes it work, then fine with me :) > > > So, what I would like to see implemented is this: ALSA hides away > > > unncessary volume controls and initializes them to sane defaults > > > (i.e. "0 dB"), and makes sure there is always a "Master" volume > > > control which is the actual control for the amplification in HW. This > > > is what Takashi has started to work on. PA already exposes this single > > > per-device volume control, and ignores all the rest the hw might > > > expose. That's volume control #1, the per-device hw-based one. > > > > > > For volume #2, the per-stream sw-based one: the PA per-stream volume > > > and the volume adjustment done in GST should be "merged". PA has all > > > the necessary APIs but Gstreamer needs some non-trivial changes for > > > this. Right now GST's mixer control is awful and designed with > > > per-device controls in mind and hardware backends. Hence I am unable > > > to expose the PA per-stream volume properly in gst-pulse. > > > > Right now, Totem and Rhythmbox have their own software-volume in the > > pipelines. Handling the "hardware" mixer that PA shows means that Totem > > and Rhythmbox would need to special-case PA. > > What I would like to see is that gst-pulse would expose a new > interface on the GstPulseSink element that allows you to modify the > per-stream volume control. In a way the current volume control > abstraction in gst is already designed to work like that, but it's for > per-device controls and totall fucked up anyway. We're mixing 2 different things. There's the per-stream volume, for the GstPulseSink for use in gnome-volume-control, and there's detecting that we have a "stream" volume, for Totem and Rhythmbox. The former I don't think is very important right now, as long as the latter is implemented. A simple read-only property would be enough to handle that. Does MacOS X present a similar interface for applications to use, or do they implement volume control by themselves like Totem/Rhythmbox currently do with the volume element? If there's something like that in MacOS X, it's a matter of agreeing on the name of the property. From walters at redhat.com Mon Aug 20 22:07:26 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 20 Aug 2007 18:07:26 -0400 Subject: low-hanging fruit In-Reply-To: <1187637896.16948.17.camel@cutter> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <20070820144052.2a5c708b@mentok.boston.redhat.com> <1187637896.16948.17.camel@cutter> Message-ID: On 8/20/07, seth vidal wrote: > > > > okay - so I understand that this is targeted for laptops and home > machines - but for people running fedora and/or rhel in a lab/classroom > this won't fly at all. Having 2 or 3 people logged in and switched is > fine. Having 500-1000 switched out won't work very well at all. Definitely, we need a way for administrators to make the "I'm leaving the computer" button be "logout". Actually...looking at the panel GConf this already exists. All the desktop spin needs to do is set /apps/panel/global/disable_log_out to true as a first step. Next, also set disable_lock_screen and make sure we lock screen from unsuspend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinverma at gmail.com Mon Aug 20 22:44:47 2007 From: kevinverma at gmail.com (Anuj Verma (Kevin)) Date: Mon, 20 Aug 2007 22:44:47 +0000 (UTC) Subject: no epiphany.i386 package for Fedora x86_64 ? References: <46C9BFB2.2040706@redhat.com> Message-ID: On Mon, 20 Aug 2007 12:22:10 -0400, Christopher Aillon wrote: > Fedora doesn't have a 32 bit package for compatibility; it's only there > because of the way multilib works. If so many apps didn't rely on it to > build against, there would be only a 64 bit version. but there is a firefox.i386 > > Now that nspluginwrapper is in rawhide though, it should be working no? > File a bug if not. yes i noticed that "nspluginwrapper" is there but it is not working right for sure. I hope to bug report it soon. From sundaram at fedoraproject.org Tue Aug 21 08:30:30 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 21 Aug 2007 14:00:30 +0530 Subject: low-hanging fruit In-Reply-To: <1187637763.4665.47.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> Message-ID: <46CAA2A6.7090905@fedoraproject.org> David Zeuthen wrote: > combined with the PackageKit work Richard is doing > > http://hughsient.livejournal.com/32948.html Going on a tangent, what's the plan with PackageKit in Fedora? How does it interact with Pirut and friends? Rahul From skvidal at fedoraproject.org Tue Aug 21 11:58:01 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 21 Aug 2007 07:58:01 -0400 Subject: low-hanging fruit In-Reply-To: <46CAA2A6.7090905@fedoraproject.org> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> Message-ID: <1187697481.16948.25.camel@cutter> On Tue, 2007-08-21 at 14:00 +0530, Rahul Sundaram wrote: > David Zeuthen wrote: > > > combined with the PackageKit work Richard is doing > > > > http://hughsient.livejournal.com/32948.html > > Going on a tangent, what's the plan with PackageKit in Fedora? How does > it interact with Pirut and friends? Given what I've read it doesn't. It's an entirely parallel structure to do installations/updates of packages. And given the feature set that Richard seems to want it will do these things mostly passwordless. I think the assumption that PackageKit should be in fedora is a bad one at the present time. It's got a long way to go and honestly, given the features it wants to support might be a problem for inclusion at all. -sv From ajackson at redhat.com Tue Aug 21 14:24:29 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 21 Aug 2007 10:24:29 -0400 Subject: low-hanging fruit In-Reply-To: <46C90AC1.7050805@prodigy.net.mx> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3F977.5060305@prodigy.net.mx> <46C40E68.4000509@fedoraproject.org> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> Message-ID: <1187706269.30336.130.camel@localhost.localdomain> On Sun, 2007-08-19 at 23:30 -0400, Gian Paolo Mureddu wrote: > Colin Walters escribi?: > > On 8/16/07, *Gian Paolo Mureddu* > > wrote: > > > > > > fine, adding sudo by default doesn't seem like very good idea for me, > > especially after my experiences with *buntu systems where the whole > > */sbin paths are visible to the regular users, > > > > But what is a "regular" user? If you have the Vista/OSX desktop spin, > > "regular users" won't ever open a terminal (or really, any application > > other than a web browser), and so the default path is completely > > irrelevant. > > > > But as a developer, when I open a terminal I want ifconfig, damn it. > Then change your .bashrc to include /sbin in the PATH, don't do it > "universally" for all users and much less *enforce* insecure practices. > Besides as I said, many of the /sbin commands run as regular users, and > just like you I don't see the "burden" to use the full path... > /sbin/ifconfig... You're seriously suggesting that putting /usr/sbin and /sbin in the default path is insecure? - ajax From ml at deadbabylon.de Tue Aug 21 14:47:54 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 21 Aug 2007 16:47:54 +0200 Subject: livecd hacking In-Reply-To: <46B8EC90.9050801@fedoraproject.org> References: <1185920349.12650.4.camel@neutron.verbum.private> <1186523586.3180.20.camel@localhost.localdomain> <46B8EC90.9050801@fedoraproject.org> Message-ID: <200708211647.59141.ml@deadbabylon.de> Am Mi 8.August 2007 schrieb Rahul Sundaram: > Matthias Clasen wrote: > > On Tue, 2007-08-07 at 17:41 -0400, Jeremy Katz wrote: > >> On Tue, 2007-08-07 at 23:07 +0200, Sebastian Vahl wrote: > >>> Am Di 7.August 2007 schrieb Jeremy Katz: > >>>> It also looks somewhat resolved out -- I bet that the list could be > >>>> shrunk somewhat -- yelp is probably the cause for libbeagle, firefox > >>>> and perhaps more. Will look closer once I get through mail hell > >>> > >>> It seems to be this way: anaconda -> zenity -> yelp -> firefox, > >>> libbeagle > >> > >> Aha, so due to anaconda's trying out zenity to see if it gives us a way > >> for people to give feedback during %post. Although it's not clear to me > >> why zenity now depends on yelp. > > > > Thats directory dependencies for you. > > Everything that installs help in /usr/share/gnome/help depends on > > yelp... > > This is not very sane. Can we get this package fixed? In reasonably > cases, the ownership guideline can have exceptions. > Any progress here? I really would like to save some space on the kde livecd. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davidz at redhat.com Tue Aug 21 16:06:49 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 21 Aug 2007 12:06:49 -0400 Subject: low-hanging fruit In-Reply-To: <1187697481.16948.25.camel@cutter> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> Message-ID: <1187712409.16413.9.camel@oneill.fubar.dk> On Tue, 2007-08-21 at 07:58 -0400, seth vidal wrote: > On Tue, 2007-08-21 at 14:00 +0530, Rahul Sundaram wrote: > > David Zeuthen wrote: > > > > > combined with the PackageKit work Richard is doing > > > > > > http://hughsient.livejournal.com/32948.html > > > > Going on a tangent, what's the plan with PackageKit in Fedora? How does > > it interact with Pirut and friends? > > Given what I've read it doesn't. It's an entirely parallel structure to > do installations/updates of packages. And given the feature set that > Richard seems to want it will do these things mostly passwordless. > > I think the assumption that PackageKit should be in fedora is a bad one > at the present time. It's got a long way to go and honestly, given the > features it wants to support might be a problem for inclusion at all. A couple of things - AFAIK there's plenty of UI package management tools besides pirut in the FPC and that's fine. Diversity, all that stuff. - When you say "should be fedora" [sic] do you mean "PackageKit should not be in Fedora Package Collection or "default in mainline Fedora"? I believe it's the latter thought I can't tell cuz you're being ambiguous. Please avoid doing that, thanks. - Note that "default in mainline Fedora" doesn't preclude the desktop spin from using PackageKit instead of Pirut. If you think about it, that's kinda of the _point_ of the desktop spin; to change the defaults from mainline Fedora to optimize the experience for a narrow set of people. - No-one says that PackageKit is ready for inclusion at all, all people, like me, say is that it's looking promising in terms of dealing with things that other projects, like Pirut, just choose to regard as non-issues / ignore. David From skvidal at fedoraproject.org Tue Aug 21 17:48:03 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 21 Aug 2007 13:48:03 -0400 Subject: low-hanging fruit In-Reply-To: <1187712409.16413.9.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> Message-ID: <1187718483.16948.59.camel@cutter> On Tue, 2007-08-21 at 12:06 -0400, David Zeuthen wrote: > A couple of things > > - AFAIK there's plenty of UI package management tools besides pirut > in the FPC and that's fine. Diversity, all that stuff. > > - When you say "should be fedora" [sic] do you mean "PackageKit should > not be in Fedora Package Collection or "default in mainline Fedora"? > I believe it's the latter thought I can't tell cuz you're being > ambiguous. Please avoid doing that, thanks. This might be a tonal issue - but you sound like a jerk when you say things like the above. You come off as fairly arrogant and unnecessarily sarcastic. It's off-putting. What I meant is given the set of features PackageKit wants to have I do not think it is a good idea and will probably be confusing if both it and Pirut are included by default in a fedora install. > > - Note that "default in mainline Fedora" doesn't preclude the desktop > spin from using PackageKit instead of Pirut. That's correct. Though I'd hope a compelling case would be made before complicating things in this way. > If you think about it, that's kinda of the _point_ of the desktop > spin; to change the defaults from mainline Fedora to optimize the > experience for a narrow set of people. Correct. Provided we don't end up sucking those things in for everyone. > - No-one says that PackageKit is ready for inclusion at all, all > people, like me, say is that it's looking promising in terms > of dealing with things that other projects, like Pirut, just choose > to regard as non-issues / ignore. good. glad to hear that. I think PackageKit is chasing us part way down a blind alley, but that's one of the options available to fedora. My saying 'I think this is a blind alley' is an option available to me. -sv From walters at redhat.com Tue Aug 21 18:04:05 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 21 Aug 2007 14:04:05 -0400 Subject: low-hanging fruit In-Reply-To: <1187712409.16413.9.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> Message-ID: On 8/21/07, David Zeuthen wrote: > > > > - Note that "default in mainline Fedora" doesn't preclude the desktop > spin from using PackageKit instead of Pirut. Hmm. That seems like a really big change to be making from mainline in a spin. I think a good goal for spin changes is to think hard about putting in changes that we do want to go down into the OS in general. For example one thing I heard people mentioning about the desktop spin is system activation; it doesn't seem to me there's a reason that couldn't be prototyped in the context of Fedora in general. I can't claim I understand exactly how yum/pirut/packagekit etc. interact but I feel like it's that level of OS change where things have to be coordinated. It feels to me that for the desktop spin we can focus on the original subject here of "low hanging fruit" and get a lot out of that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Tue Aug 21 18:25:45 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 21 Aug 2007 14:25:45 -0400 Subject: low-hanging fruit In-Reply-To: <20070820000735.GA24281@tango.0pointer.de> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187280287.2718.17.camel@localhost.localdomain> <1187284974.17169.4.camel@localhost.localdomain> <1187287477.2718.31.camel@localhost.localdomain> <1187287835.17169.13.camel@localhost.localdomain> <20070816141730.3356f3c3@mentok.boston.redhat.com> <1187314217.26239.34.camel@cookie.hadess.net> <20070820000735.GA24281@tango.0pointer.de> Message-ID: <20070821182545.GB2682@redhat.com> On Mon, Aug 20, 2007 at 02:07:35AM +0200, Lennart Poettering wrote: > > This probably needs UI love, and use of D-Bus instead of Unix sockets > > for the admin rights, but the idea is there. > > Fieryfilter used the userspace QUEUE netfilter target to do its > work. That sucked big time, because if the user didn't click away his > dialogs quick enough the sender would repeat its packet which is > difficult to deal with if you don't want to accumulate dialogs for the > same packets. > > If someone wants to investigate the whole desktop firewall for Linux > thing a little more I think it would make more sense to write an LSM > module for that kernel that intercepts the socket calls (i.e, > accept(), listen(), connect() and friends) and relays them to > userspace for a verdict. Would be much cleaner and simpler. And would > also be a good excuse to keep LSM in the kernel. ;-) > > (Hmm, that could also be integrated with PolicyKit...) > > Last time I looked it was difficult to stack LSMs, hence this all is > not trivial. Something that's coming soon is an option to use selinux without LSM (paraphrasing, but it gets the idea across). The stacking ability of LSMs never really worked, and has been removed now afaik. With the removal of LSM, SELinux gets a performance increase, and also removes a bunch of potential attack vectors. So adding new functionality based on LSM would be a mistake. Dave -- http://www.codemonkey.org.uk From davidz at redhat.com Tue Aug 21 18:34:52 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 21 Aug 2007 14:34:52 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> Message-ID: <1187721292.16413.33.camel@oneill.fubar.dk> On Tue, 2007-08-21 at 14:04 -0400, Colin Walters wrote: > On 8/21/07, David Zeuthen wrote: > > > - Note that "default in mainline Fedora" doesn't preclude the > desktop > spin from using PackageKit instead of Pirut. > > Hmm. That seems like a really big change to be making from mainline > in a spin. I think a good goal for spin changes is to think hard > about putting in changes that we do want to go down into the OS in > general. Hey, let's not get carried away; this is not a OS-level change, it's, in effect, simply just another UI frontend for yum, not much different from pirut/pup, yumex, whatever except that it's designed to solve the problem in a much nicer way (at least some of us think) both from a technical point and an user experience point of view. There's no reason to fear change. David From walters at redhat.com Tue Aug 21 18:42:11 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 21 Aug 2007 14:42:11 -0400 Subject: low-hanging fruit In-Reply-To: <1187721292.16413.33.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> Message-ID: On 8/21/07, David Zeuthen wrote: > > > Hey, let's not get carried away; this is not a OS-level change, it's, in > effect, simply just another UI frontend for yum, not much different from > pirut/pup, yumex, whatever except that it's designed to solve the > problem in a much nicer way (at least some of us think) both from a > technical point and an user experience point of view. There's no reason > to fear change. Ok, fair enough then. You'd be the first to accuse me of fearing change! =) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidz at redhat.com Tue Aug 21 18:44:47 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 21 Aug 2007 14:44:47 -0400 Subject: low-hanging fruit In-Reply-To: <1187718483.16948.59.camel@cutter> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187718483.16948.59.camel@cutter> Message-ID: <1187721887.16413.43.camel@oneill.fubar.dk> On Tue, 2007-08-21 at 13:48 -0400, seth vidal wrote: > This might be a tonal issue - but you sound like a jerk when you say > things like the above. You come off as fairly arrogant and unnecessarily > sarcastic. It's off-putting. Sorry, but I overreacted because I was (and still is) slightly annoyed about the tone your message that I replied to. I'll try to be more diplomatic in the future. > What I meant is given the set of features PackageKit wants to have I do > not think it is a good idea and will probably be confusing if both it > and Pirut are included by default in a fedora install. No one is proposing that; that would be like installing two web browsers in a default install. > > - No-one says that PackageKit is ready for inclusion at all, all > > people, like me, say is that it's looking promising in terms > > of dealing with things that other projects, like Pirut, just choose > > to regard as non-issues / ignore. > > good. glad to hear that. I think PackageKit is chasing us part way down > a blind alley, but that's one of the options available to fedora. My > saying 'I think this is a blind alley' is an option available to me. You are entitled to your opinion. But also respect that people doing spins / livecd's are entitled to selecting the packages they want. Personally, I think that's a good thing. David From skvidal at fedoraproject.org Tue Aug 21 23:21:22 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 21 Aug 2007 19:21:22 -0400 Subject: low-hanging fruit In-Reply-To: <1187721887.16413.43.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C4555C.3020202@prodigy.net.mx> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187718483.16948.59.camel@cutter> <1187721887.16413.43.camel@oneill.fubar.dk> Message-ID: <1187738482.16948.65.camel@cutter> On Tue, 2007-08-21 at 14:44 -0400, David Zeuthen wrote: > On Tue, 2007-08-21 at 13:48 -0400, seth vidal wrote: > > This might be a tonal issue - but you sound like a jerk when you say > > things like the above. You come off as fairly arrogant and unnecessarily > > sarcastic. It's off-putting. > > Sorry, but I overreacted because I was (and still is) slightly annoyed > about the tone your message that I replied to. I'll try to be more > diplomatic in the future. Ah - then we were both suffering from the same problem. My tone was not intended to be hostile - my tone was questioning, though. My apologies for the miscommunication. -sv From skvidal at fedoraproject.org Tue Aug 21 23:23:48 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 21 Aug 2007 19:23:48 -0400 Subject: low-hanging fruit In-Reply-To: <1187721292.16413.33.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> Message-ID: <1187738628.16948.69.camel@cutter> On Tue, 2007-08-21 at 14:34 -0400, David Zeuthen wrote: > On Tue, 2007-08-21 at 14:04 -0400, Colin Walters wrote: > > On 8/21/07, David Zeuthen wrote: > > > > > > - Note that "default in mainline Fedora" doesn't preclude the > > desktop > > spin from using PackageKit instead of Pirut. > > > > Hmm. That seems like a really big change to be making from mainline > > in a spin. I think a good goal for spin changes is to think hard > > about putting in changes that we do want to go down into the OS in > > general. > > Hey, let's not get carried away; this is not a OS-level change, it's, in > effect, simply just another UI frontend for yum, not much different from > pirut/pup, yumex, whatever except that it's designed to solve the > problem in a much nicer way (at least some of us think) both from a > technical point and an user experience point of view. There's no reason > to fear change. > >From a technical point it doesn't solve the problem in a different way at all. I've been helping Richard with scripts to backend packagekit with yum and the scripts are extremely simple. To be clear - some of the user experience items are really just papering over the security questions and hoping no one notices that right now PackageKit is the equivalent of: yum -y do_whatever_just_be_quiet_about_it. -sv From tiagomatos at gmail.com Wed Aug 22 10:24:53 2007 From: tiagomatos at gmail.com (Rui Tiago =?ISO-8859-1?Q?Ca=E7=E3o?= Matos) Date: Wed, 22 Aug 2007 11:24:53 +0100 Subject: low-hanging fruit In-Reply-To: <1187738628.16948.69.camel@cutter> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> Message-ID: <1187778293.10011.20.camel@hive> Hi, I usually lurk here. I think this Desktop spin is a very fine idea. Finally people are thinking about the final user experience. On Ter, 2007-08-21 at 19:23 -0400, seth vidal wrote: > >From a technical point it doesn't solve the problem in a different way > at all. I've been helping Richard with scripts to backend packagekit > with yum and the scripts are extremely simple. To be clear - some of the > user experience items are really just papering over the security > questions and hoping no one notices that right now PackageKit is the > equivalent of: > > yum -y do_whatever_just_be_quiet_about_it. As far as I understood from Richard's blog your comparison here is very superficial. For instance, if you do that on an xterm and then for some reason your X crashes, or you log out because you forgot about it, yum will crash too, and leave you RPM db hosed. PackageKit is supposed to continue working even without anyone logged in. It allows a "fire and forget" asynchronous action. Besides, it should allow integration with the preferred applications metric from the online-desktop so people can have a simple way to choose a new app to install without having to understand all the package names etc. I don't think any of the standard yum tools allows this. More generally, I think that all these new *Kit daemons as well as HAL, NM, and D-Bus, that enables them all, are urgently needed for a much more organic and dynamic desktop experience which has humans controlling their computer and not the other way around. Kudos to everyone working on them! Rui -------------- 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 jkeating at redhat.com Wed Aug 22 11:39:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 07:39:26 -0400 Subject: low-hanging fruit In-Reply-To: <1187778293.10011.20.camel@hive> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <1187778293.10011.20.camel@hive> Message-ID: <20070822073926.60398f74@ender> On Wed, 22 Aug 2007 11:24:53 +0100 Rui Tiago Ca??o Matos wrote: > As far as I understood from Richard's blog your comparison here is > very superficial. For instance, if you do that on an xterm and then > for some reason your X crashes, or you log out because you forgot > about it, yum will crash too, and leave you RPM db hosed. PackageKit > is supposed to continue working even without anyone logged in. It > allows a "fire and forget" asynchronous action. Besides, it should > allow integration with the preferred applications metric from the > online-desktop so people can have a simple way to choose a new app to > install without having to understand all the package names etc. I > don't think any of the standard yum tools allows this. > > More generally, I think that all these new *Kit daemons as well as > HAL, NM, and D-Bus, that enables them all, are urgently needed for a > much more organic and dynamic desktop experience which has humans > controlling their computer and not the other way around. Kudos to > everyone working on them! While Seth's post was very simple, it does highlight the basic problem that many of us have with PackageKit as a whole. All the other things it's trying to achieve are neat, but the fact that what it allows is what Seth wrote is what gives many of us the hives. But then again many of us are used to thinking about things in a vastly different (well may be not /that/ vastly) way. -- 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 bnocera at redhat.com Wed Aug 22 12:54:19 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 22 Aug 2007 13:54:19 +0100 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C90AC1.7050805@prodigy.net.mx> <20070820123536.6d1ff920@mentok.boston.redhat.com> <1187633340.4665.11.camel@oneill.fubar.dk> <20070820144052.2a5c708b@mentok.boston.redhat.com> <20070820150214.5da68e9f@mentok.boston.redhat.com> Message-ID: <1187787259.3208.127.camel@cookie.hadess.net> On Mon, 2007-08-20 at 15:18 -0400, Colin Walters wrote: > On 8/20/07, Jesse Keating wrote: > > I don't suspend when walking away because I don't want my > wireless to > drop, I don't want to have to re-login to say t-mobile > hot-spot, > > Yeah, sigh...these wifi browser prompts completely destroy the user > experience for so many applications. My personal favorite is starting > Firefox, clicking "Resume session" and getting 15 redirected login > tabs. > > Long term I hope we can figure out some way to make that suck less. I > don't have any good ideas right now about how to detect the situation > initially. Devicescape-like for GNOME? http://www.devicescape.com > That said though, maybe if we only suspend for say the time it takes > to go to the bathroom (~2 minutes) it might not toss you back at that > prompt. I'm not sure how that works - if it authorizes your MAC > address for X minutes or whether it's "DHCP request implies prompt". > In the latter case we might be able to fix NetworkManager to save its > DHCP lease if it's within the lease time still and not do another > request on unsuspend if it's the same network. It still needs the WEP key (unset on suspend) to resume. And gnome-screensaver should probably unlock the keyring if it can. From otaylor at redhat.com Wed Aug 22 14:18:52 2007 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 22 Aug 2007 10:18:52 -0400 Subject: low-hanging fruit In-Reply-To: <1187738628.16948.69.camel@cutter> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> Message-ID: <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> On 8/21/07, seth vidal wrote: > > On Tue, 2007-08-21 at 14:34 -0400, David Zeuthen wrote: > > On Tue, 2007-08-21 at 14:04 -0400, Colin Walters wrote: > > > On 8/21/07, David Zeuthen wrote: > > > > > > > > > - Note that "default in mainline Fedora" doesn't preclude the > > > desktop > > > spin from using PackageKit instead of Pirut. > > > > > > Hmm. That seems like a really big change to be making from mainline > > > in a spin. I think a good goal for spin changes is to think hard > > > about putting in changes that we do want to go down into the OS in > > > general. > > > > Hey, let's not get carried away; this is not a OS-level change, it's, in > > effect, simply just another UI frontend for yum, not much different from > > pirut/pup, yumex, whatever except that it's designed to solve the > > problem in a much nicer way (at least some of us think) both from a > > technical point and an user experience point of view. There's no reason > > to fear change. > > > > >From a technical point it doesn't solve the problem in a different way > at all. I've been helping Richard with scripts to backend packagekit > with yum and the scripts are extremely simple. To be clear - some of the > user experience items are really just papering over the security > questions and hoping no one notices that right now PackageKit is the > equivalent of: > > yum -y do_whatever_just_be_quiet_about_it. I have a *strong* opinion here that it's *never*, *ever* right to ask the user a question when installing or removing a package. A question is going to be of the form: A) This operation may trash your system [detail that the user doesn't understand removed]. Proceed? B) The package that you are installing might be created by an evil haxor and do bad things [details that the user doesn't understand removed]. Proceed? The user has no basis on which to make the decisions, and all you've done is created some coverage for yourself when they continue anyways and bad things happen. And when I say "the user doesn't understand", I'm not being dismissive of some imaginary naive, clueless user. *I* almost never understand the details in such cases. I do think it's important for something like PackageKit to return maximally descriptive error messages to the user; I was quite concerned when I saw Richard post that everything had to be turned into an error enum in PackageKit so that the translation could be done in the front end. I think that's just wrong, and you always want error message *strings* to be part of the system, translated at the source when applicable. [ The above obviously neglects the type of question like "installing this package is going to result in installing OpenOffice.org, and downloading 300megs of extra packages, taking 3 hours, proceed? Which is legitimate to ask the user. I think that type of question, is, however, generic enough to be part of a system like PackageKit ] From skvidal at fedoraproject.org Wed Aug 22 14:28:14 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 22 Aug 2007 10:28:14 -0400 Subject: low-hanging fruit In-Reply-To: <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> Message-ID: <1187792894.16948.155.camel@cutter> On Wed, 2007-08-22 at 10:18 -0400, Owen Taylor wrote: > On 8/21/07, seth vidal wrote: > > > > On Tue, 2007-08-21 at 14:34 -0400, David Zeuthen wrote: > > > On Tue, 2007-08-21 at 14:04 -0400, Colin Walters wrote: > > > > On 8/21/07, David Zeuthen wrote: > > > > > > > > > > > > - Note that "default in mainline Fedora" doesn't preclude the > > > > desktop > > > > spin from using PackageKit instead of Pirut. > > > > > > > > Hmm. That seems like a really big change to be making from mainline > > > > in a spin. I think a good goal for spin changes is to think hard > > > > about putting in changes that we do want to go down into the OS in > > > > general. > > > > > > Hey, let's not get carried away; this is not a OS-level change, it's, in > > > effect, simply just another UI frontend for yum, not much different from > > > pirut/pup, yumex, whatever except that it's designed to solve the > > > problem in a much nicer way (at least some of us think) both from a > > > technical point and an user experience point of view. There's no reason > > > to fear change. > > > > > > > >From a technical point it doesn't solve the problem in a different way > > at all. I've been helping Richard with scripts to backend packagekit > > with yum and the scripts are extremely simple. To be clear - some of the > > user experience items are really just papering over the security > > questions and hoping no one notices that right now PackageKit is the > > equivalent of: > > > > yum -y do_whatever_just_be_quiet_about_it. > > I have a *strong* opinion here that it's *never*, *ever* right to ask > the user a question when installing or removing a package. A question > is going to be of the form: > > A) This operation may trash your system [detail that the user doesn't > understand removed]. Proceed? > > B) The package that you are installing might be created by an evil > haxor and do bad things [details that the user doesn't understand > removed]. Proceed? > > The user has no basis on which to make the decisions, and all you've > done is created some coverage for yourself when they continue anyways > and bad things happen. And when I say "the user doesn't understand", > I'm not being dismissive of some imaginary naive, clueless user. *I* > almost never understand the details in such cases. > > I do think it's important for something like PackageKit to return > maximally descriptive error messages to the user; I was quite > concerned when I saw Richard post that everything had to be turned > into an error enum in PackageKit so that the translation could be done > in the front end. I think that's just wrong, and you always want error > message *strings* to be part of the system, translated at the source > when applicable. > > [ The above obviously neglects the type of question like "installing > this package is going to result in installing OpenOffice.org, and > downloading 300megs of extra packages, taking 3 hours, proceed? Which > is legitimate to ask the user. I think that type of question, is, > however, generic enough to be part of a system like PackageKit ] I'm a little bothered that you're picking and choosing which questions you think users can answer. I think users can intelligibly understand statements about gpg keys. The difference here is that I'm assuming that users are smarter and/or capable of using google to understand what's going on. I know this is a cliche - but if you assume your users are stupid, then you end up with stupid users. Now, for a lot of yum questions we don't assume the user is stupid, we assume the user is not present. (ie: unattended cron or daemon-drive runs). I understand the virtue of making the defaults make sense. I also understand the virtue of not showing up on bugtraq b/c you auto-import gpg keys w/o so much as a notice about it. -sv From jkeating at redhat.com Wed Aug 22 14:34:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 10:34:58 -0400 Subject: low-hanging fruit In-Reply-To: <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> Message-ID: <20070822103458.1d438577@mentok.boston.redhat.com> On Wed, 22 Aug 2007 10:18:52 -0400 "Owen Taylor" wrote: > I have a *strong* opinion here that it's *never*, *ever* right to ask > the user a question when installing or removing a package. A question > is going to be of the form: > > A) This operation may trash your system [detail that the user doesn't > understand removed]. Proceed? > > B) The package that you are installing might be created by an evil > haxor and do bad things [details that the user doesn't understand > removed]. Proceed? For me it's not asking the users these questions, it's asking the user for their password to proceed (with a timeout). OSX does this, and we seem to base a lot of our "good usability" on what they do. If a friend wants to just look at their web mail, why should they switch users to a guest account? Why can't I just hand them the laptop and let them use the already running browser? If something popped up to install software I don't want them to be able to just have it happen, I want the password prompt to show up so that if they aren't me, or weren't me that provided a password in the last 5 minutes, I don't want them to be able to do it. I don't think this is unreasonable as a default everywhere. It's just like we made the local user(s) sudo enabled and rely upon that sudo mechanism to accomplish system level tasks. -- 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 jon.nettleton at gmail.com Wed Aug 22 14:49:24 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 22 Aug 2007 10:49:24 -0400 Subject: low-hanging fruit In-Reply-To: <20070822103458.1d438577@mentok.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <20070822103458.1d438577@mentok.boston.redhat.com> Message-ID: On 8/22/07, Jesse Keating wrote: > On Wed, 22 Aug 2007 10:18:52 -0400 > "Owen Taylor" wrote: > > > I have a *strong* opinion here that it's *never*, *ever* right to ask > > the user a question when installing or removing a package. A question > > is going to be of the form: > > > > A) This operation may trash your system [detail that the user doesn't > > understand removed]. Proceed? > > > > B) The package that you are installing might be created by an evil > > haxor and do bad things [details that the user doesn't understand > > removed]. Proceed? > > For me it's not asking the users these questions, it's asking the user > for their password to proceed (with a timeout). OSX does this, and we > seem to base a lot of our "good usability" on what they do. If a > friend wants to just look at their web mail, why should they switch > users to a guest account? Why can't I just hand them the laptop and > let them use the already running browser? If something popped up to > install software I don't want them to be able to just have it happen, I > want the password prompt to show up so that if they aren't me, or > weren't me that provided a password in the last 5 minutes, I don't want > them to be able to do it. I don't think this is unreasonable as a > default everywhere. It's just like we made the local user(s) sudo > enabled and rely upon that sudo mechanism to accomplish system level > tasks. > The other half of this is it should not just be the users password that is acceptable. We need to make sure an admin can sit down at a machine and perform these operations without mucking around with profiles or switch terminals. This functionality is becoming more and more necessary, where children have a restricted desktop. We want to make it very easy for parents (admins) to install a new game for their kids in a straight forward manner. From rstrode at redhat.com Wed Aug 22 14:50:26 2007 From: rstrode at redhat.com (Ray Strode) Date: Wed, 22 Aug 2007 10:50:26 -0400 Subject: low-hanging fruit In-Reply-To: <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> Message-ID: <1187794226.2524.35.camel@halflap.boston.devel.redhat.com> Hi, > I do think it's important for something like PackageKit to return > maximally descriptive error messages to the user; I was quite > concerned when I saw Richard post that everything had to be turned > into an error enum in PackageKit so that the translation could be done > in the front end. I think that's just wrong, and you always want error > message *strings* to be part of the system, translated at the source > when applicable. This is kind of a side point (but then again PackageKit isn't anywhere near done, yet, so this entire sub-thread is pretty much a side point for a low-hanging fruit thread), but while I agree translated strings should come from the source, it's important to realize that the system language isn't the same as the session language in many cases. What I'm saying is, the daemon should be sending msgid's and translation domains up (in the gettext sense), instead of translated msgstr's or there should be some protocol to send the locale down before translated strings get sent up. --Ray From btatehome at gmail.com Wed Aug 22 15:03:04 2007 From: btatehome at gmail.com (Brian Tate) Date: Wed, 22 Aug 2007 11:03:04 -0400 Subject: low-hanging fruit In-Reply-To: <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> Message-ID: <46CC5028.7050104@gmail.com> Hello, I imagine all the talk about this new "spin" is an official spin? I've heard it referred to as a "windows xp/mac os x" style spin. This kind of phrasing doesn't live well in my ears. I left those proprietary blobs to get away from the over-rated usability of these OSes. Is it a good goal for the Fedora project to really adopt a policy to make "Desktop" spin that doesn't introduce the user to tried-and-true security practices like the root account? (thats just one example I've seen listed in this thread) Sure it may make it more easily-adoptable perhaps then slightly more user adoption, but for completely the wrong reasons. Also, I would think it'd be bad if a user downloads the "Desktop" version of Fedora and then decides to try the "Fedora" spin of Fedora and has a completely different user experience. If people want to spend time on a more "user-friendly" spin, I guess more power to them, but certainly a "let's follow windows/mac" mentality shouldn't be the mission statement. Maybe I don't understand the "Desktop"-distro market, I've always considered my computer more of a workstation. -Brian From jkeating at redhat.com Wed Aug 22 15:06:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 11:06:07 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <20070822103458.1d438577@mentok.boston.redhat.com> Message-ID: <20070822110607.481cdde8@ender> On Wed, 22 Aug 2007 10:49:24 -0400 "Jon Nettleton" wrote: > The other half of this is it should not just be the users password > that is acceptable. We need to make sure an admin can sit down at a > machine and perform these operations without mucking around with > profiles or switch terminals. This functionality is becoming more and > more necessary, where children have a restricted desktop. We want to > make it very easy for parents (admins) to install a new game for their > kids in a straight forward manner. Yes, there is that. Thanks for mentioning it. -- 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 sundaram at fedoraproject.org Wed Aug 22 15:21:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 22 Aug 2007 20:51:33 +0530 Subject: low-hanging fruit In-Reply-To: <46CC5028.7050104@gmail.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <46CC5028.7050104@gmail.com> Message-ID: <46CC547D.6030303@fedoraproject.org> Brian Tate wrote: > Hello, > > I imagine all the talk about this new "spin" is an official spin? > I've heard it referred to as a "windows xp/mac os x" style spin. This > kind of phrasing doesn't live well in my ears. I left those proprietary > blobs to get away from the over-rated usability of these OSes. The user experience isn't tied to the license or development model. , I guess more power to them, > but certainly a "let's follow windows/mac" mentality shouldn't be the > mission statement. I don't see that as a goal in http://fedoraproject.org/wiki/SIGs/Desktop. Did you read? Rahul From davidz at redhat.com Wed Aug 22 15:29:53 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 22 Aug 2007 11:29:53 -0400 Subject: low-hanging fruit In-Reply-To: <20070822103458.1d438577@mentok.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <20070822103458.1d438577@mentok.boston.redhat.com> Message-ID: <1187796593.2903.18.camel@oneill.fubar.dk> On Wed, 2007-08-22 at 10:34 -0400, Jesse Keating wrote: > For me it's not asking the users these questions, it's asking the user > for their password to proceed (with a timeout). OSX does this, and we > seem to base a lot of our "good usability" on what they do. > If a > friend wants to just look at their web mail, why should they switch > users to a guest account? Why can't I just hand them the laptop and > let them use the already running browser? Because you don't want your auto completion / browser history (e.g. porn), already existing sessions (banks, social networks, gmail, other sites) made available to your friends? > If something popped up to > install software I don't want them to be able to just have it happen, I > want the password prompt to show up so that if they aren't me, or > weren't me that provided a password in the last 5 minutes, I don't want > them to be able to do it. So on one hand you want to give your friend access to your *entire* browser history / cookies etc. and on the other hand you will not give them access to install packages from your already configured repositories? Anyway, one criticism I've heard about this whole thing is that it's "passwordless" and that's just not true unless you want it to be that way. So the defaults for PackageKit in *mainline Fedora* should probably be pkgkit.update.signed.packages -> auth_admin_keep_always - meaning you need to auth as root [1] and there's a fire-and-forget "always remember this privilege" checkbox in the auth dialog) pkgkit.update.unsigned.packages -> auth_admin - meaning you need to auth as root, this privilege cannot be kept pkgkit.install.signed.packages -> auth_admin_keep_always - meaning you need to auth as yourself and there's a fire-and-forget "always remember this privilege" checkbox) pkgkit.install.unsigned.packages -> auth_admin - meaning you need to auth as root, privilege cannot be kept. This can be customized through /etc/PolicyKit/PolicyKit.conf. For example, I envision we ship with this a configuration file that always prevents the guest account from doing this. In addition, the desktop spin will probably be passwordless for pkgkit.update.signed.packages or whatever we decide - doing this is achieved simply by editing PolicyKit.conf in the %post of the live cd creator. It's that simple really. FWIW, any administrator can go in and change this as they see fit. For example, I can add to specify that all interactions with PackageKit always should ask for the root password and that the privilege can't be retained. Or I can do this to specify that users davidz and jkeating can use PackageKit without using a password and no one else can even attempt to auth for this. So it's pretty flexible as you can see. See the man page for PolicyKit.conf for details. David [1] : unless you configure PolicyKit to act as a sudo-ish system and defines administrator authentication as "anyone from group wheel will do". From btatehome at gmail.com Wed Aug 22 15:38:33 2007 From: btatehome at gmail.com (Brian Tate) Date: Wed, 22 Aug 2007 11:38:33 -0400 Subject: low-hanging fruit In-Reply-To: <46CC547D.6030303@fedoraproject.org> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <46CC5028.7050104@gmail.com> <46CC547D.6030303@fedoraproject.org> Message-ID: <46CC5879.304@gmail.com> Rahul Sundaram wrote: > Brian Tate wrote: >> Hello, >> >> I imagine all the talk about this new "spin" is an official spin? >> I've heard it referred to as a "windows xp/mac os x" style spin. This >> kind of phrasing doesn't live well in my ears. I left those >> proprietary blobs to get away from the over-rated usability of these >> OSes. > > The user experience isn't tied to the license or development model. Really? We need to get Richard Stallman in on this one. > > , I guess more power to them, >> but certainly a "let's follow windows/mac" mentality shouldn't be the >> mission statement. > > I don't see that as a goal in > http://fedoraproject.org/wiki/SIGs/Desktop. Did you read? I guess I was referring more to the talk on the thread, less of the posted on the website content. > > Rahul > Brian From walters at redhat.com Wed Aug 22 15:41:57 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 22 Aug 2007 11:41:57 -0400 Subject: low-hanging fruit In-Reply-To: <46CC5028.7050104@gmail.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <46CC5028.7050104@gmail.com> Message-ID: On 8/22/07, Brian Tate wrote: > > tried-and-true > security practices like the root account? What is secure about a root account? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Wed Aug 22 15:44:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 22 Aug 2007 21:14:16 +0530 Subject: low-hanging fruit In-Reply-To: <46CC5879.304@gmail.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187636148.4665.31.camel@oneill.fubar.dk> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <46CC5028.7050104@gmail.com> <46CC547D.6030303@fedoraproject.org> <46CC5879.304@gmail.com> Message-ID: <46CC59D0.10607@fedoraproject.org> Brian Tate wrote: > Rahul Sundaram wrote: >> Brian Tate wrote: >>> Hello, >>> >>> I imagine all the talk about this new "spin" is an official spin? >>> I've heard it referred to as a "windows xp/mac os x" style spin. This >>> kind of phrasing doesn't live well in my ears. I left those >>> proprietary blobs to get away from the over-rated usability of these >>> OSes. >> >> The user experience isn't tied to the license or development model. > > Really? We need to get Richard Stallman in on this one. Get whomever you want or explain how one is tied up to another. We have seen similar user experiences in either models. Rahul From walters at redhat.com Wed Aug 22 15:47:43 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 22 Aug 2007 11:47:43 -0400 Subject: low-hanging fruit In-Reply-To: <20070822103458.1d438577@mentok.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <20070822103458.1d438577@mentok.boston.redhat.com> Message-ID: On 8/22/07, Jesse Keating wrote: > > If something popped up to > install software What would pop up to install new software? And why would your friend click it? Wouldn't he or she ask you about it? Also remember - you don't need root or a password to install software to your computer. You just download something that overwrites your ~/.bashrc, puts itself in ~/.config/autostart, or one of many other methods. Like firefox extensions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From otaylor at redhat.com Wed Aug 22 16:24:52 2007 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 22 Aug 2007 12:24:52 -0400 Subject: low-hanging fruit In-Reply-To: <1187792894.16948.155.camel@cutter> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <1187792894.16948.155.camel@cutter> Message-ID: <190e0dab0708220924v42db2f7fned8d5f4f7a45c531@mail.gmail.com> On 8/22/07, seth vidal wrote: > I'm a little bothered that you're picking and choosing which questions > you think users can answer. I think users can intelligibly understand > statements about gpg keys. The difference here is that I'm assuming that > users are smarter and/or capable of using google to understand what's > going on. I'm perfectly willing to concede that user are *able* to understand these messages if they take the time. They probably have a college degree, assemble furniture with cryptic instructions translated from Japanese, and file their taxes every April. But what I don't concede is that they *want to* understand these messages or *will bother* to understand these messages. I see no value training up our users to understand how to import GPG keys into RPM. Our users should be spending their brain cells designing bridges and curing cancer. (And maybe buying shoes on Ebay too). Our job is to make package installation not consume those brain cells. This has all strayed off pretty far into theory-land. Maybe you can give a concrete example of a concrete case (starting with why the user is in the GUI tool to begin with) of when a user needs to be asked a yum-specific question when interacting with a GUI tool? - Owen From skvidal at fedoraproject.org Wed Aug 22 16:34:35 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 22 Aug 2007 12:34:35 -0400 Subject: low-hanging fruit In-Reply-To: <190e0dab0708220924v42db2f7fned8d5f4f7a45c531@mail.gmail.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <1187792894.16948.155.camel@cutter> <190e0dab0708220924v42db2f7fned8d5f4f7a45c531@mail.gmail.com> Message-ID: <1187800475.16948.166.camel@cutter> On Wed, 2007-08-22 at 12:24 -0400, Owen Taylor wrote: > On 8/22/07, seth vidal wrote: > > > I'm a little bothered that you're picking and choosing which questions > > you think users can answer. I think users can intelligibly understand > > statements about gpg keys. The difference here is that I'm assuming that > > users are smarter and/or capable of using google to understand what's > > going on. > > I'm perfectly willing to concede that user are *able* to understand > these messages if they take the time. They probably have a college > degree, assemble furniture with cryptic instructions translated from > Japanese, and file their taxes every April. But what I don't concede > is that they *want to* understand these messages or *will bother* to > understand these messages. > > I see no value training up our users to understand how to import GPG > keys into RPM. Our users should be spending their brain cells > designing bridges and curing cancer. (And maybe buying shoes on Ebay > too). Our job is to make package installation not consume those brain > cells. > > This has all strayed off pretty far into theory-land. Maybe you can > give a concrete example of a concrete case (starting with why the user > is in the GUI tool to begin with) of when a user needs to be asked a > yum-specific question when interacting with a GUI tool? - import a gpg key from a repo so they can install a package. - verify that the set of things they are asking to install/remove/obsolete is what they _really_ want to do. - let them know they need to reboot/logout/restart-some-program in order to have these changes take effect. We've got to get some information to them b/c the internet isn't error-free. :) -sv From hughsient at gmail.com Wed Aug 22 16:46:47 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 22 Aug 2007 17:46:47 +0100 Subject: PackageKit Misconceptions Message-ID: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> Hi guys. I've been pointed to the "low-hanging fruit" discussion on this list by a couple of people. I wasn't on this list, but now am. So what is PackageKit: ? A daemon that accepts asynchronous jobs. ? A way of letting certain groups of people do stuff to the package database with a fine grained server-client security model. ? A system service that starts only when needed. ? A way of inhibiting suspend/hibernate/restart/shutdown when performing actions. ? An interface to a packaging backend. The fine grained security model allows an installer application to be loaded as the user (without a root password), to do searches without a password, and to only ask the user for authentication for any privileged task, for instance updating the system or installing a package. This lets the admin decide what level of security is best for the box in question. [http://people.freedesktop.org/~hughsient/temp/pk-polkit.png] A packaging backend can be something in a thread like libapt-pkg (as it has a C++ binding) or using a polling backend with external helper scripts for stuff like yum (python) or urpmi (perl) with no C bindings. The helper scripts communicate over stdin, stderr and stdout using a loosly defined (by the backend) protocol, in an effort to make scripted synchronous operations into async ones with a common DBUS interface. I've started to define this here: [http://gitweb.freedesktop.org/?p=users/hughsient/PackageKit.git;a=blob_plain;f=helpers/README] What is Packagekit-gnome: ? An lightweight update applet that runs once per logged in user that refreshes the cache at startup and displays update status and critical security warnings. [http://people.freedesktop.org/~hughsient/temp/pk-updates-warning.png] ? A way of seeing what other users are doing with PackageKit, so you can see why the hdd light is flashing after doing a fast user switch somewhere else. ? An application installer. Note, gnome-app-install is probably going to be the long term target as this will be ported to the PackageKit API. [http://people.freedesktop.org/~hughsient/temp/pk-application2.png] So, misconceptions in the thread so far (in my opinion): Pirut and PackageKit are mutually exclusive: You can happily run them both side by side. I am now. If pirut is open then PK should queue the request until pirut is closed. PackageKit is vapourware: Nope, I'm running it right now. True, only the dummy backend is supported but the apt and yum backends are coming on. The deps are also pretty harsh; you need PolicyKit, dbus-glib, dbus and PolicyKit-gnome all from git. F8 rpm's for PackageKit are in my repo [http://people.freedesktop.org/~hughsient/fedora/]. PackageKit API is rubbish: I know. It's unstable right now, and is changing to fulfill all the use-cases. My view is you have to let an API evolve to be optimal, rather than over-engineer everything when the complexities are not known. [http://people.freedesktop.org/~hughsient/temp/pk-interface.xml] Error enums will not be powerful enough Fair enough, I hear you loud and clear. Maybe we can set a hint to the backend about the locale, but I would have to think about this more. PackageKit will be included in F9/F10/desktop-spin/crackpot-spin That's up to you guys. I think it will be some time before the API is stable, and all the UI and policy bits and bobs are worked out. PackageKit also needs a security code review as sometimes it's running as the root user. So, the short story is I'm not pushing this to be included in fedora right now, as it can only do 10% of what the current tools can do. PackageKit allows you to install stuff without a password Well, it allows the admin to set what sort of authentication you need to do each action, be it your own password, an admins password, or just to deny the request. PackageKit is yet another system daemon to be started at boot time: Nope, it's started only when needed using system activation, and quits a few seconds after finishing it's last queued task. We are just a layer over yum -y --ask-no-questions: If PackageKit is just a layer, I think the layer allows us to do some important things the old system could not, and allows us to share code between distros and desktop projects. Also, my view is that questions should never be asked. Who has ever clicked no to "Load GPG key from Fedora Project"? Is there a legal requirement to show such a warning? So, I hope that has cleared things up a bit. Comments and suggestions welcome. Thanks, Richard Hughes. From davidz at redhat.com Wed Aug 22 17:11:29 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 22 Aug 2007 13:11:29 -0400 Subject: low-hanging fruit In-Reply-To: <1187800475.16948.166.camel@cutter> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <1187792894.16948.155.camel@cutter> <190e0dab0708220924v42db2f7fned8d5f4f7a45c531@mail.gmail.com> <1187800475.16948.166.camel@cutter> Message-ID: <1187802689.2903.55.camel@oneill.fubar.dk> On Wed, 2007-08-22 at 12:34 -0400, seth vidal wrote: > - import a gpg key from a repo so they can install a package. ... which is an interesting and very technical way of describing trust. Which I think it is about, yes? E.g. asking whether a software provider should be trusted. Deciding to trust someone is of course important. Assuming only Fedora repos are used (e.g. fedora, fedora-updates, whatever), people wouldn't see this anyway, right? So I just tried with yum > warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, > key ID a109b1ec > Importing GPG key 0xA109B1EC "Livna.org rpms " > from /etc/pki/rpm-gpg/RPM-GPG-KEY-livna > Is this ok [y/N]: y which, I guess, is perfectly fine for a tool designed for system administrators. (Except, maybe yum should specifically mention that this is about setting up a trust relationship, then again, it's probably fine to assume the person seeing this knows that is what it means.) However, wouldn't it be possible to phrase the question to the user in a way where GPG keys are not mentioned at all? For example +-------------------------------------------------------------------+ | Do you trust "Livna.org rpms ?" | | | | The software you are trying to install comes from an source | | that can't be verified. | | | | [Cancel] [I trust this provider] | | | | > Details (GtkExpander) | +-------------------------------------------------------------------+ The details might include techno-babble like the GPG key finger print (probably should) but it could also integrate with existing desktop-specific GPG software, e.g. Seahorse which, IIRC, already have some way of examining trust relationships. Also, the details bit could be made useful; we could try to determine what contacts of yours actually trust this provider (online desktop, social networking); we could look up on your online account if you've decided to trust this provider before so your computer can avoid asking you again the next time you are on a different system. Web of trusts, etc. These are just some thoughts. Dialogs and questions like these are always difficult (my example above is already too verbose). (Another technical tidbit: RPM's GPG keys are tied to the system so when one user is deciding to import a GPG (aka. start trusting a software provider) it affects all users on that. Maybe the dialog need to makes that clear too.) > - verify that the set of things they are asking to > install/remove/obsolete is what they _really_ want to do. I honestly think such users should just use the system administrator tool, e.g. yum(1). But sure, we could work this into the UI but am unsure it's a good idea. Do you have any concrete examples from the history of the stable Fedora Package Collection where this is relevant? > - let them know they need to reboot/logout/restart-some-program in order > to have these changes take effect. We need this. I don't expect it to be difficult to do either. David From caillon at redhat.com Wed Aug 22 17:26:55 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 22 Aug 2007 13:26:55 -0400 Subject: Reminder: Desktop SIG meeting today 2pm EDT (1800 UTC) Message-ID: <46CC71DF.6030704@redhat.com> http://fedoraproject.org/wiki/SIGs/Desktop This is approximately 33 minutes from now. From jkeating at redhat.com Wed Aug 22 17:31:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 13:31:00 -0400 Subject: PackageKit Misconceptions In-Reply-To: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> Message-ID: <20070822133100.5f2daedb@mentok.boston.redhat.com> On Wed, 22 Aug 2007 17:46:47 +0100 "Richard Hughes" wrote: > Also, my view is that questions should never be asked. Who has ever > clicked no to "Load GPG key from Fedora Project"? Is there a legal > requirement to show such a warning? > > So, I hope that has cleared things up a bit. Comments and suggestions > welcome. There aren't requirements, however given that our software is mirrored around the world and our tools are made easy to make your own Fedora, it's possible that somebody could start handing out spoofed Fedoras. If the key you're asking to import says it's Fedora, but the public key servers don't match this key, that's a very quick indication that you should stop using the system as it's been compromised in some way. Also it's easy enough to install some piece of software off the net that drops a yum repo file in place and starts handing you packages from another repo. You should get the opportunity to confirm your trust in this repo before it starts replacing all kinds of packages in your system.. (now said packages that drop a repo file could just easily set gpgcheck=no and bypass all the trust issues, but that's neither here nor there) I will happily admit that our dialogs don't say any of this and just assume that the user "gets" all this automatically. -- 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 drago01 at gmail.com Wed Aug 22 17:37:20 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 22 Aug 2007 19:37:20 +0200 Subject: low-hanging fruit In-Reply-To: <1187802689.2903.55.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <1187792894.16948.155.camel@cutter> <190e0dab0708220924v42db2f7fned8d5f4f7a45c531@mail.gmail.com> <1187800475.16948.166.camel@cutter> <1187802689.2903.55.camel@oneill.fubar.dk> Message-ID: On 8/22/07, David Zeuthen wrote: > > > > (Another technical tidbit: RPM's GPG keys are tied to the system so when > one user is deciding to import a GPG (aka. start trusting a software > provider) it affects all users on that. Maybe the dialog need to makes > that clear too.) that is a reason for asking for the root password , everything else is nothing but a security hole if a non root user can set system defaults like this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Wed Aug 22 17:40:39 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 22 Aug 2007 18:40:39 +0100 Subject: PackageKit Misconceptions In-Reply-To: <20070822133100.5f2daedb@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> Message-ID: <15e53e180708221040w6d8285aena3d6609a295f0029@mail.gmail.com> On 22/08/07, Jesse Keating wrote: > Also it's easy enough to install some piece of software off the net > that drops a yum repo file in place and starts handing you packages > from another repo. You should get the opportunity to confirm your > trust in this repo before it starts replacing all kinds of packages in > your system.. > (now said packages that drop a repo file could just easily set > gpgcheck=no and bypass all the trust issues, but that's neither here > nor there) I think it is very important actually. If a malicious package is putting files in random places as the root user (installing a package manually using rpm) then we've essentially lost security on the system as far as I'm concerned. You could take this argument one step further and a malicious package could be designed to patch yum/rpm to not do the gpg checks. Richard. From davidz at redhat.com Wed Aug 22 17:37:30 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 22 Aug 2007 13:37:30 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <1187792894.16948.155.camel@cutter> <190e0dab0708220924v42db2f7fned8d5f4f7a45c531@mail.gmail.com> <1187800475.16948.166.camel@cutter> <1187802689.2903.55.camel@oneill.fubar.dk> Message-ID: <1187804250.2903.59.camel@oneill.fubar.dk> On Wed, 2007-08-22 at 19:37 +0200, dragoran wrote: > > > On 8/22/07, David Zeuthen wrote: > > > (Another technical tidbit: RPM's GPG keys are tied to the > system so when > one user is deciding to import a GPG (aka. start trusting a > software > provider) it affects all users on that. Maybe the dialog need > to makes > that clear too.) > > that is a reason for asking for the root password , everything else is > nothing but a security hole if a non root user can set system > defaults like this. Yeah, it's probably a good idea to ask for an administrator to authenticate to do this. With mainline Fedora this would be asking for the root password; for other spins it might asking a user in e.g. 'wheel' to authenticate. David From caillon at redhat.com Wed Aug 22 17:44:31 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 22 Aug 2007 13:44:31 -0400 Subject: PackageKit Misconceptions In-Reply-To: <20070822133100.5f2daedb@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> Message-ID: <46CC75FF.7070502@redhat.com> Jesse Keating wrote: > If the key you're asking to import says it's Fedora Why isn't Fedora's key imported by default? From jon.nettleton at gmail.com Wed Aug 22 17:47:42 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 22 Aug 2007 13:47:42 -0400 Subject: low-hanging fruit In-Reply-To: <1187804250.2903.59.camel@oneill.fubar.dk> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <1187792894.16948.155.camel@cutter> <190e0dab0708220924v42db2f7fned8d5f4f7a45c531@mail.gmail.com> <1187800475.16948.166.camel@cutter> <1187802689.2903.55.camel@oneill.fubar.dk> <1187804250.2903.59.camel@oneill.fubar.dk> Message-ID: On 8/22/07, David Zeuthen wrote: > > On Wed, 2007-08-22 at 19:37 +0200, dragoran wrote: > > > > > > On 8/22/07, David Zeuthen wrote: > > > > > > (Another technical tidbit: RPM's GPG keys are tied to the > > system so when > > one user is deciding to import a GPG (aka. start trusting a > > software > > provider) it affects all users on that. Maybe the dialog need > > to makes > > that clear too.) > > > > that is a reason for asking for the root password , everything else is > > nothing but a security hole if a non root user can set system > > defaults like this. > > Yeah, it's probably a good idea to ask for an administrator to > authenticate to do this. With mainline Fedora this would be asking for > the root password; for other spins it might asking a user in e.g. > 'wheel' to authenticate. > which reminds me. wouldn't it make sense to at UGROUPS=wheel to our /etc/security/console.apps/ files? The functionality has been around for years now and never used because it was getting replaced. Jon From davidz at redhat.com Wed Aug 22 17:49:44 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 22 Aug 2007 13:49:44 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <1187792894.16948.155.camel@cutter> <190e0dab0708220924v42db2f7fned8d5f4f7a45c531@mail.gmail.com> <1187800475.16948.166.camel@cutter> <1187802689.2903.55.camel@oneill.fubar.dk> <1187804250.2903.59.camel@oneill.fubar.dk> Message-ID: <1187804984.2903.63.camel@oneill.fubar.dk> On Wed, 2007-08-22 at 13:47 -0400, Jon Nettleton wrote: > which reminds me. wouldn't it make sense to at UGROUPS=wheel to our > /etc/security/console.apps/ files? The functionality has been around > for years now > and never used because it was getting replaced. I'd much rather see us stop shipping X11 applications that run as root and, for that matter, consolehelper too. At least in the default install. (That said, I've been toying around with writing a consolehelper replacement using PolicyKit; it's not a lot of work and the immediate benefit is that you can use the /etc/PolicyKit/PolicyKit.conf mechanism to control access; the most immediate benefit being the "fire-and-forget" feature that you get with the remember authorization check boxes.) David From jkeating at redhat.com Wed Aug 22 17:53:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 13:53:30 -0400 Subject: PackageKit Misconceptions In-Reply-To: <46CC75FF.7070502@redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <46CC75FF.7070502@redhat.com> Message-ID: <20070822135330.1395dc00@mentok.boston.redhat.com> On Wed, 22 Aug 2007 13:44:31 -0400 Christopher Aillon wrote: > Why isn't Fedora's key imported by default? For the reason I listed above, we don't control the distribution of Fedora. We hand it out to mirrors and encourage people download it from !us. We can import the RHEL key by default because we control the distribution mechanism. You can only get RHEL through us. -- 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 walters at redhat.com Wed Aug 22 17:55:19 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 22 Aug 2007 13:55:19 -0400 Subject: PackageKit Misconceptions In-Reply-To: <20070822133100.5f2daedb@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> Message-ID: On 8/22/07, Jesse Keating wrote: > > > There aren't requirements, however given that our software is mirrored > around the world and our tools are made easy to make your own Fedora, > it's possible that somebody could start handing out spoofed Fedoras. > If the key you're asking to import says it's Fedora, but the public key > servers don't match this key, that's a very quick indication that you > should stop using the system as it's been compromised in some way. Jean is a physics researcher at CERN. He installed Fedora on his workstation because he's developing some parallel computation software related to his hypothesis using MPI, and he likes Linux as a development environment. He is helping to discover the fundamental properties of the universe. Jean is smarter than anyone posting in this thread. People keep making the assumption that reducing questions is designing for "dumb" users. In fact, we're designing for users who have *more important things to do*. We should make sure we're not stopping Jean in the middle of his work with a question like "Do you trust this hex number?". It's not that he couldn't answer it, but we certainly don't make it easy to do so "correctly" (which I guess is browsing to pgp.mit.edu and manually entering the hex number and making some sort of wild guess based on other signatures). The obvious default policy to me is: * Fedora trusts the GPG keys it ships * All other keys are denied The scenario where this does break down is installing software from other sites like livna. If we have some sort of hoop there in the process that's probably fine. Maybe you have to "sudo rpm -ivh http://livna.org/gpg.asc", or click some dialog. Firefox makes users installing extensions wait 3 seconds. What I would do is be very realistic though - 99.99% of people are just going to click "OK" to random dialogs popping up, and there is nothing we can do to change that. Also it's easy enough to install some piece of software off the net > that drops a yum repo file in place and starts handing you packages > from another repo. If you installed an RPM from an untrusted source, you have already lost. It can execute arbitrary code in %post, or overwrite /lib/libc.so, the possibilities are endless. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidz at redhat.com Wed Aug 22 17:53:40 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 22 Aug 2007 13:53:40 -0400 Subject: PackageKit Misconceptions In-Reply-To: <20070822135330.1395dc00@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <46CC75FF.7070502@redhat.com> <20070822135330.1395dc00@mentok.boston.redhat.com> Message-ID: <1187805220.2903.66.camel@oneill.fubar.dk> On Wed, 2007-08-22 at 13:53 -0400, Jesse Keating wrote: > On Wed, 22 Aug 2007 13:44:31 -0400 > Christopher Aillon wrote: > > > Why isn't Fedora's key imported by default? > > For the reason I listed above, we don't control the distribution of > Fedora. We hand it out to mirrors and encourage people download it > from !us. We can import the RHEL key by default because we control the > distribution mechanism. You can only get RHEL through us. Assume that Alice gets Fedora from Mallory's mirror. What prevents Mallory from patching the rpm and yum programs that end up on Alice's system to avoid honoring the keys that we, painfully, make her import? David From jkeating at redhat.com Wed Aug 22 18:01:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 14:01:13 -0400 Subject: PackageKit Misconceptions In-Reply-To: References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> Message-ID: <20070822140113.3e9bd789@mentok.boston.redhat.com> On Wed, 22 Aug 2007 13:55:19 -0400 "Colin Walters" wrote: > If you installed an RPM from an untrusted source, you have already > lost. It can execute arbitrary code in %post, or > overwrite /lib/libc.so, the possibilities are endless. So basically what you're saying is that we should just give up and go home. Right? Do we seriously just want to give everybody full root access and let whatever happens happens, never asking them to think a second about what they're clicking or doing? Basically windows95/98 mentality? "Oh, well we'll just allow them to install software from configured repos." That's great, how do you add repos, because Fedora by design doesn't have everything a user wants. "Oh, we'll well just allow them to install a package from a website that has the repo files in it." Game over. Hey it'd be neat if we didn't have to think about security anymore. We could focus on a lot of the other cool stuff we want to do. No questions, no checking, just have at it! -- 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 davidz at redhat.com Wed Aug 22 17:58:51 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 22 Aug 2007 13:58:51 -0400 Subject: PackageKit Misconceptions In-Reply-To: <1187805220.2903.66.camel@oneill.fubar.dk> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <46CC75FF.7070502@redhat.com> <20070822135330.1395dc00@mentok.boston.redhat.com> <1187805220.2903.66.camel@oneill.fubar.dk> Message-ID: <1187805531.2903.71.camel@oneill.fubar.dk> On Wed, 2007-08-22 at 13:53 -0400, David Zeuthen wrote: > On Wed, 2007-08-22 at 13:53 -0400, Jesse Keating wrote: > > On Wed, 22 Aug 2007 13:44:31 -0400 > > Christopher Aillon wrote: > > > > > Why isn't Fedora's key imported by default? > > > > For the reason I listed above, we don't control the distribution of > > Fedora. We hand it out to mirrors and encourage people download it > > from !us. We can import the RHEL key by default because we control the > > distribution mechanism. You can only get RHEL through us. > > Assume that Alice gets Fedora from Mallory's mirror. What prevents > Mallory from patching the rpm and yum programs that end up on Alice's > system to avoid honoring the keys that we, painfully, make her import? (and if the answer is "Alice checks the MD5 sum of the ISO against something from an official Fedora website that she trusts" (unlikely, but..) then you just proved my case that including the GPG keys on the ISO itself is fine too.) David From davidz at redhat.com Wed Aug 22 18:02:47 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 22 Aug 2007 14:02:47 -0400 Subject: PackageKit Misconceptions In-Reply-To: <20070822140113.3e9bd789@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> Message-ID: <1187805767.2903.75.camel@oneill.fubar.dk> On Wed, 2007-08-22 at 14:01 -0400, Jesse Keating wrote: > Hey it'd be neat if we didn't have to think about security anymore. We > could focus on a lot of the other cool stuff we want to do. No > questions, no checking, just have at it! To me, that's totally not what Colin is suggesting. In fact, there are things in his mail that actually suggests to *improve* security such as replacing, IMO, useless dialogs like "Import this GPG key: " to something more useful (his proposal about timeouts). See also my other mail about asking better questions like "Import this GPG key: ". David From jkeating at redhat.com Wed Aug 22 18:11:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 14:11:41 -0400 Subject: PackageKit Misconceptions In-Reply-To: <1187805767.2903.75.camel@oneill.fubar.dk> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> Message-ID: <20070822141141.4ccdde10@mentok.boston.redhat.com> On Wed, 22 Aug 2007 14:02:47 -0400 David Zeuthen wrote: > To me, that's totally not what Colin is suggesting. In fact, there are > things in his mail that actually suggests to *improve* security such > as replacing, IMO, useless dialogs like "Import this GPG key: > " to something more useful (his proposal about timeouts). > See also my other mail about asking better questions like "Import > this GPG key: ". I got from it that he just wants to do away with the question entirely. I'm having a hard time figuring out where you guys want to go. In one hand you say you don't want dialogs at all that ask people to think or even respond, it just does things. On the other you say as soon as you allow installing software that is outside of the repos we ship, the jig is up and we shouldn't care about any sort of security form that point on. I'm lost :( -- 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 jkeating at redhat.com Wed Aug 22 18:12:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 14:12:59 -0400 Subject: PackageKit Misconceptions In-Reply-To: <1187805220.2903.66.camel@oneill.fubar.dk> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <46CC75FF.7070502@redhat.com> <20070822135330.1395dc00@mentok.boston.redhat.com> <1187805220.2903.66.camel@oneill.fubar.dk> Message-ID: <20070822141259.6ffa3763@mentok.boston.redhat.com> On Wed, 22 Aug 2007 13:53:40 -0400 David Zeuthen wrote: > Assume that Alice gets Fedora from Mallory's mirror. What prevents > Mallory from patching the rpm and yum programs that end up on Alice's > system to avoid honoring the keys that we, painfully, make her import? I honestly don't have an answer for this. They could. Should we then just throw out any and all verification utilities? That would make life easier. -- 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 krh at bitplanet.net Wed Aug 22 18:15:30 2007 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Wed, 22 Aug 2007 14:15:30 -0400 Subject: PackageKit Misconceptions In-Reply-To: <20070822141259.6ffa3763@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <46CC75FF.7070502@redhat.com> <20070822135330.1395dc00@mentok.boston.redhat.com> <1187805220.2903.66.camel@oneill.fubar.dk> <20070822141259.6ffa3763@mentok.boston.redhat.com> Message-ID: <59ad55d30708221115q2ba6c99ejee79b42e8c444b02@mail.gmail.com> On 8/22/07, Jesse Keating wrote: > On Wed, 22 Aug 2007 13:53:40 -0400 > David Zeuthen wrote: > > > Assume that Alice gets Fedora from Mallory's mirror. What prevents > > Mallory from patching the rpm and yum programs that end up on Alice's > > system to avoid honoring the keys that we, painfully, make her import? > > I honestly don't have an answer for this. They could. Should we then > just throw out any and all verification utilities? That would make > life easier. No, that's not the point. The MD5 checksum we have in place now are useful and should be kept. The point is that with those measures in place, why don't we just ship the Fedora GPG by default? Kristian From walters at redhat.com Wed Aug 22 18:17:06 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 22 Aug 2007 14:17:06 -0400 Subject: PackageKit Misconceptions In-Reply-To: <20070822140113.3e9bd789@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> Message-ID: On 8/22/07, Jesse Keating wrote: > > > So basically what you're saying is that we should just give up and go > home. Right? Do we seriously just want to give everybody full root > access and let whatever happens happens, never asking them to think a > second about what they're clicking or doing? Basically windows95/98 > mentality? Right now you can install new software on Fedora 7 out of the box - without entering a password - by browsing to: http://addons.mozilla.org So, you do not need root access to screw yourself over. Really, everything not under /home (i.e. under "root" control) is basically unimportant infrastructure goo. How do I know this? Because almost every time I've tried to upgrade Fedora something has gone wrong, so I've just preserved my /home, blown away my disk, reinstalled, and reinstated /home and been at basically the same point I was before. Just have to enable passwordless sudo. No one has really solved the problem of trojan software. Dialogs are definitely not a solution. Now, we can have a dialog for it and I wouldn't argue against it - but we shouldn't delude ourselves into thinking that having people enter a password is going to stop them from getting their MP3s to play. -------------- next part -------------- An HTML attachment was scrubbed... URL: From otaylor at redhat.com Wed Aug 22 18:24:04 2007 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 22 Aug 2007 14:24:04 -0400 Subject: low-hanging fruit In-Reply-To: <1187800475.16948.166.camel@cutter> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <1187792894.16948.155.camel@cutter> <190e0dab0708220924v42db2f7fned8d5f4f7a45c531@mail.gmail.com> <1187800475.16948.166.camel@cutter> Message-ID: <190e0dab0708221124q65e38733u86152a4afd22fd6b@mail.gmail.com> On 8/22/07, seth vidal wrote: > On Wed, 2007-08-22 at 12:24 -0400, Owen Taylor wrote: > > This has all strayed off pretty far into theory-land. Maybe you can > > give a concrete example of a concrete case (starting with why the user > > is in the GUI tool to begin with) of when a user needs to be asked a > > yum-specific question when interacting with a GUI tool? > > > - import a gpg key from a repo so they can install a package. > - verify that the set of things they are asking to > install/remove/obsolete is what they _really_ want to do. > - let them know they need to reboot/logout/restart-some-program in order > to have these changes take effect. > > We've got to get some information to them b/c the internet isn't > error-free. :) Well, in general terms, if the PackageKit API doesn't provide enough richness to provide the right interaction, it needs to be improved. Certainly verification of what is going to happen makes sense to me as part of that API. Rebooting / logout / restarting has to be handled as well (though you can't tell the user, "I upgraded libglib, please restart all apps you are using that depend upon it") Specifically I think the GPG key import is probably one of those questions where the user clicks yes unless the question is "Do you want to import the GPG key for bad-guy-wants-to-take-over-your-computer.com?" And it isn't going say that when a bad guy wants to take over your computer. The mechanism to ask the question doesn't make sense without answering the design question of how doe a users start using packages from a new repository in a way that doesn't involve asking them "if you are being tricked, press cancel". - Owen From jkeating at redhat.com Wed Aug 22 18:28:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 14:28:52 -0400 Subject: PackageKit Misconceptions In-Reply-To: <59ad55d30708221115q2ba6c99ejee79b42e8c444b02@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <46CC75FF.7070502@redhat.com> <20070822135330.1395dc00@mentok.boston.redhat.com> <1187805220.2903.66.camel@oneill.fubar.dk> <20070822141259.6ffa3763@mentok.boston.redhat.com> <59ad55d30708221115q2ba6c99ejee79b42e8c444b02@mail.gmail.com> Message-ID: <20070822142852.5a7de57d@mentok.boston.redhat.com> On Wed, 22 Aug 2007 14:15:30 -0400 "Kristian H?gsberg" wrote: > No, that's not the point. The MD5 checksum we have in place now are > useful and should be kept. The point is that with those measures in > place, why don't we just ship the Fedora GPG by default? *shrug* I'm rapidly losing energy for this talk, and thus I can't think of too many reasonable reasons why not. If there is an overwhelming desire to do this, I won't stand in the way, but we should do it for Fedora in general and not as a change just for the Desktop Live image. (and I'd like to get the input from our security folks too) -- 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 jkeating at redhat.com Wed Aug 22 18:32:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 14:32:50 -0400 Subject: PackageKit Misconceptions In-Reply-To: References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> Message-ID: <20070822143250.0b2d3330@mentok.boston.redhat.com> On Wed, 22 Aug 2007 14:17:06 -0400 "Colin Walters" wrote: > No one has really solved the problem of trojan software. Dialogs are > definitely not a solution. Now, we can have a dialog for it and I > wouldn't argue against it - but we shouldn't delude ourselves into > thinking that having people enter a password is going to stop them > from getting their MP3s to play. It's not about stopping them from getting mp3s, but whatever. "We want better dialogs that aren't technobabble". I agree wholeheartedly. "We want to allow for (and default to) some level of auth before allowing installing software/writing to outside your home dir". Again in agreement. Your browser question is only so so. Sure you can install stuff to your home dir, but you can't compromise other users on the system. -- 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 davidz at redhat.com Wed Aug 22 18:29:39 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 22 Aug 2007 14:29:39 -0400 Subject: PackageKit Misconceptions In-Reply-To: <20070822141141.4ccdde10@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> Message-ID: <1187807379.2903.81.camel@oneill.fubar.dk> On Wed, 2007-08-22 at 14:11 -0400, Jesse Keating wrote: > On Wed, 22 Aug 2007 14:02:47 -0400 > David Zeuthen wrote: > > > To me, that's totally not what Colin is suggesting. In fact, there are > > things in his mail that actually suggests to *improve* security such > > as replacing, IMO, useless dialogs like "Import this GPG key: > > " to something more useful (his proposal about timeouts). > > See also my other mail about asking better questions like "Import > > this GPG key: ". > > I got from it that he just wants to do away with the question > entirely. I'm having a hard time figuring out where you guys want to > go. In one hand you say you don't want dialogs at all that ask people > to think or even respond, it just does things. On the other you say as > soon as you allow installing software that is outside of the repos we > ship, the jig is up and we shouldn't care about any sort of security > form that point on. I'm lost :( That's not how I read the thread. Basically - We should include Fedora GPG keys by default. See https://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00285.html why this is a good idea. - Have some dialogs that are actually *useful* when you try to install software that comes from outside Fedora. See https://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00274.html https://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00279.html for some ideas. Is it more clear now? David From davidz at redhat.com Wed Aug 22 18:30:22 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 22 Aug 2007 14:30:22 -0400 Subject: PackageKit Misconceptions In-Reply-To: <20070822142852.5a7de57d@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <46CC75FF.7070502@redhat.com> <20070822135330.1395dc00@mentok.boston.redhat.com> <1187805220.2903.66.camel@oneill.fubar.dk> <20070822141259.6ffa3763@mentok.boston.redhat.com> <59ad55d30708221115q2ba6c99ejee79b42e8c444b02@mail.gmail.com> <20070822142852.5a7de57d@mentok.boston.redhat.com> Message-ID: <1187807422.2903.83.camel@oneill.fubar.dk> On Wed, 2007-08-22 at 14:28 -0400, Jesse Keating wrote: > On Wed, 22 Aug 2007 14:15:30 -0400 > "Kristian H?gsberg" wrote: > > > No, that's not the point. The MD5 checksum we have in place now are > > useful and should be kept. The point is that with those measures in > > place, why don't we just ship the Fedora GPG by default? > > *shrug* I'm rapidly losing energy for this talk, and thus I can't > think of too many reasonable reasons why not. If there is an > overwhelming desire to do this, I won't stand in the way, but we should > do it for Fedora in general and not as a change just for the Desktop > Live image. (and I'd like to get the input from our security folks too) Sure. Against which component should we file a bug? David From jkeating at redhat.com Wed Aug 22 18:38:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 14:38:08 -0400 Subject: PackageKit Misconceptions In-Reply-To: <1187807422.2903.83.camel@oneill.fubar.dk> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <46CC75FF.7070502@redhat.com> <20070822135330.1395dc00@mentok.boston.redhat.com> <1187805220.2903.66.camel@oneill.fubar.dk> <20070822141259.6ffa3763@mentok.boston.redhat.com> <59ad55d30708221115q2ba6c99ejee79b42e8c444b02@mail.gmail.com> <20070822142852.5a7de57d@mentok.boston.redhat.com> <1187807422.2903.83.camel@oneill.fubar.dk> Message-ID: <20070822143808.66b9bbf6@mentok.boston.redhat.com> On Wed, 22 Aug 2007 14:30:22 -0400 David Zeuthen wrote: > Sure. Against which component should we file a bug? I'm not entirely sure where we'd want to do this. It has to be ran as the root user on the system (or somebody with sudo access) after the install has completed. Anaconda? Firstboot? -- 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 davidz at redhat.com Wed Aug 22 18:37:10 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 22 Aug 2007 14:37:10 -0400 Subject: PackageKit Misconceptions In-Reply-To: <20070822143808.66b9bbf6@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <46CC75FF.7070502@redhat.com> <20070822135330.1395dc00@mentok.boston.redhat.com> <1187805220.2903.66.camel@oneill.fubar.dk> <20070822141259.6ffa3763@mentok.boston.redhat.com> <59ad55d30708221115q2ba6c99ejee79b42e8c444b02@mail.gmail.com> <20070822142852.5a7de57d@mentok.boston.redhat.com> <1187807422.2903.83.camel@oneill.fubar.dk> <20070822143808.66b9bbf6@mentok.boston.redhat.com> Message-ID: <1187807830.2903.85.camel@oneill.fubar.dk> On Wed, 2007-08-22 at 14:38 -0400, Jesse Keating wrote: > On Wed, 22 Aug 2007 14:30:22 -0400 > David Zeuthen wrote: > > > Sure. Against which component should we file a bug? > > I'm not entirely sure where we'd want to do this. It has to be ran as > the root user on the system (or somebody with sudo access) after the > install has completed. Anaconda? Firstboot? Why? Can't we just include the GPG keys in the fedora-release package? David From otaylor at redhat.com Wed Aug 22 18:47:37 2007 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 22 Aug 2007 14:47:37 -0400 Subject: PackageKit Misconceptions In-Reply-To: <20070822141141.4ccdde10@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> Message-ID: <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> On 8/22/07, Jesse Keating wrote: > On Wed, 22 Aug 2007 14:02:47 -0400 > David Zeuthen wrote: > > > To me, that's totally not what Colin is suggesting. In fact, there are > > things in his mail that actually suggests to *improve* security such > > as replacing, IMO, useless dialogs like "Import this GPG key: > > " to something more useful (his proposal about timeouts). > > See also my other mail about asking better questions like "Import > > this GPG key: ". > > I got from it that he just wants to do away with the question > entirely. I'm having a hard time figuring out where you guys want to > go. In one hand you say you don't want dialogs at all that ask people > to think or even respond, it just does things. On the other you say as > soon as you allow installing software that is outside of the repos we > ship, the jig is up and we shouldn't care about any sort of security > form that point on. I'm lost :( You are missing the fact that the action we take without asking the user doesn't have to be "accept" it can be "deny". And "deny" doesn't mean that "we're taking capabilities away from the user", it means "people are forced to think about how this really should have worked". Asking the user is usually a cop-out for bad design and laziness. For example, imagine that we enhance our system so that so anyone can have a one click link on their website to add their GPG key and yum repository, and we've done the work so: A) The information displayed to the user has been audited to be accurate B) We provide some sort of reputation system displayed right along with the question so that you have a basis for an informed decision C) We check that you are downloading the information over a secure channel Then Livna can put such a link on their web site along with instructions. And it works out vastly better rather than asking someone if they like a hex string or not. - Owen From jkeating at redhat.com Wed Aug 22 18:52:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Aug 2007 14:52:32 -0400 Subject: PackageKit Misconceptions In-Reply-To: <1187807830.2903.85.camel@oneill.fubar.dk> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <46CC75FF.7070502@redhat.com> <20070822135330.1395dc00@mentok.boston.redhat.com> <1187805220.2903.66.camel@oneill.fubar.dk> <20070822141259.6ffa3763@mentok.boston.redhat.com> <59ad55d30708221115q2ba6c99ejee79b42e8c444b02@mail.gmail.com> <20070822142852.5a7de57d@mentok.boston.redhat.com> <1187807422.2903.83.camel@oneill.fubar.dk> <20070822143808.66b9bbf6@mentok.boston.redhat.com> <1187807830.2903.85.camel@oneill.fubar.dk> Message-ID: <20070822145232.1036158d@mentok.boston.redhat.com> On Wed, 22 Aug 2007 14:37:10 -0400 David Zeuthen wrote: > Why? Can't we just include the GPG keys in the fedora-release package? We do. However we can't import them into the rpm database. Well, /maybe/ we can in %post, but that doesn't sound right. -- 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 davidz at redhat.com Wed Aug 22 19:05:13 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 22 Aug 2007 15:05:13 -0400 Subject: PackageKit Misconceptions In-Reply-To: <20070822145232.1036158d@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <46CC75FF.7070502@redhat.com> <20070822135330.1395dc00@mentok.boston.redhat.com> <1187805220.2903.66.camel@oneill.fubar.dk> <20070822141259.6ffa3763@mentok.boston.redhat.com> <59ad55d30708221115q2ba6c99ejee79b42e8c444b02@mail.gmail.com> <20070822142852.5a7de57d@mentok.boston.redhat.com> <1187807422.2903.83.camel@oneill.fubar.dk> <20070822143808.66b9bbf6@mentok.boston.redhat.com> <1187807830.2903.85.camel@oneill.fubar.dk> <20070822145232.1036158d@mentok.boston.redhat.com> Message-ID: <1187809513.2903.92.camel@oneill.fubar.dk> On Wed, 2007-08-22 at 14:52 -0400, Jesse Keating wrote: > On Wed, 22 Aug 2007 14:37:10 -0400 > David Zeuthen wrote: > > > Why? Can't we just include the GPG keys in the fedora-release package? > > We do. However we can't import them into the rpm database. > Well, /maybe/ we can in %post, but that doesn't sound right. That's what I meant, yeah %post. I've filed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253897 to track this. Thanks. David From hughsient at gmail.com Wed Aug 22 19:35:36 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 22 Aug 2007 20:35:36 +0100 Subject: low-hanging fruit In-Reply-To: <190e0dab0708221124q65e38733u86152a4afd22fd6b@mail.gmail.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <1187792894.16948.155.camel@cutter> <190e0dab0708220924v42db2f7fned8d5f4f7a45c531@mail.gmail.com> <1187800475.16948.166.camel@cutter> <190e0dab0708221124q65e38733u86152a4afd22fd6b@mail.gmail.com> Message-ID: <15e53e180708221235u2e7913d2ue88ee1bf4c7bc360@mail.gmail.com> On 22/08/07, Owen Taylor wrote: > Well, in general terms, if the PackageKit API doesn't provide enough > richness to provide the right interaction, it needs to be improved. > Certainly verification of what is going to happen makes sense to me as > part of that API. Rebooting / logout / restarting has to be handled as > well (though you can't tell the user, "I upgraded libglib, please > restart all apps you are using that depend upon it") Yup, I'm working on that now. Richard. From nicolas.mailhot at laposte.net Wed Aug 22 20:19:24 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Aug 2007 22:19:24 +0200 Subject: Round 3 Default Artwork Decision In-Reply-To: <46CC9345.7090601@redhat.com> References: <46CC9345.7090601@redhat.com> Message-ID: <1187813964.1994.12.camel@rousalka.dyndns.org> Le mercredi 22 ao?t 2007 ? 15:49 -0400, M?ir?n Duffy a ?crit : > It still needs: > > - CD boot menu > - firstboot banner & splash (could reuse anaconda splash) > - Normal boot menu background (grub) > - RHGB theme > - GDM theme (we can do a graphical greeter if we provide the theme so i > can write it) > - if we need splashes for gnome and KDE, the anaconda splash design > should work well with minor modifications Please check with the desktop group, I think at least some of those won't be needed by the new F8 boot process -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From drago01 at gmail.com Wed Aug 22 20:33:22 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 22 Aug 2007 22:33:22 +0200 Subject: Round 3 Default Artwork Decision In-Reply-To: <1187813964.1994.12.camel@rousalka.dyndns.org> References: <46CC9345.7090601@redhat.com> <1187813964.1994.12.camel@rousalka.dyndns.org> Message-ID: On 8/22/07, Nicolas Mailhot wrote: > > > Le mercredi 22 ao?t 2007 ? 15:49 -0400, M?ir?n Duffy a ?crit : > > > It still needs: > > > > - CD boot menu > > - firstboot banner & splash (could reuse anaconda splash) > > - Normal boot menu background (grub) > > - RHGB theme > > - GDM theme (we can do a graphical greeter if we provide the theme so i > > can write it) > > - if we need splashes for gnome and KDE, the anaconda splash design > > should work well with minor modifications > > Please check with the desktop group, I think at least some of those > won't be needed by the new F8 boot process boot process wont change in f8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Wed Aug 22 21:13:38 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Aug 2007 13:13:38 -0800 Subject: PackageKit Misconceptions In-Reply-To: <1187805220.2903.66.camel@oneill.fubar.dk> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <46CC75FF.7070502@redhat.com> <20070822135330.1395dc00@mentok.boston.redhat.com> <1187805220.2903.66.camel@oneill.fubar.dk> Message-ID: <604aa7910708221413n26413c8dx8f78fcd33fd4d770@mail.gmail.com> On 8/22/07, David Zeuthen wrote: > Assume that Alice gets Fedora from Mallory's mirror. What prevents > Mallory from patching the rpm and yum programs that end up on Alice's > system to avoid honoring the keys that we, painfully, make her import? would signing our mirror metadata help? would importing the provided keys at install time help? (We have to assume the install media is trusted) -jef From jspaleta at gmail.com Wed Aug 22 21:23:02 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Aug 2007 13:23:02 -0800 Subject: PackageKit Misconceptions In-Reply-To: <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> Message-ID: <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> On 8/22/07, Owen Taylor wrote: > A) The information displayed to the user has been audited to be accurate You have a proposal on how to do this? I have grave concerns about being legally allowed to do this in a centralize way as part of the Fedora project. > B) We provide some sort of reputation system displayed right along > with the question so that you have a basis for an informed decision Uhm... probably not possible. I seriously doubt that we could officially host a ranking of 3rd party sources in fedora controlled infrastructure. We go out of our way to not officially communicate about 3rd party repos. I have a very hard time seeing how this is going to be integrated into a Fedora experience with the Fedora Project acting as the central broker of reputation. -jef From nicolas.mailhot at laposte.net Wed Aug 22 21:02:44 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Aug 2007 23:02:44 +0200 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1187637763.4665.47.camel@oneill.fubar.dk> <46CAA2A6.7090905@fedoraproject.org> <1187697481.16948.25.camel@cutter> <1187712409.16413.9.camel@oneill.fubar.dk> <1187721292.16413.33.camel@oneill.fubar.dk> <1187738628.16948.69.camel@cutter> <190e0dab0708220718l519b19f4s34d69962edcfca86@mail.gmail.com> <20070822103458.1d438577@mentok.boston.redhat.com> Message-ID: <1187816564.1994.19.camel@rousalka.dyndns.org> Le mercredi 22 ao?t 2007 ? 11:47 -0400, Colin Walters a ?crit : > On 8/22/07, Jesse Keating wrote: > If something popped up to > install software > > What would pop up to install new software? Helpful apps that want to help you install every pluggin known (including plugins like flash that require a complete 32bit stack on a 64bit system to run) > And why would your friend click it? Because users have a railroad approach to popups (just click yes) > Wouldn't he or she ask you about it? Friends don't ask about every popup they click through when they get guest access (or they don't stay friends long) > Also remember - you don't need root or a password to install software > to your computer. You just download something that overwrites your > ~/.bashrc, puts itself in ~/.config/autostart, or one of many other > methods. Like firefox extensions. Firefox extensions are a security plague and a great example why password-less install is bad in a guest context. I hope with FF3 we can start packaging the useful subset everyone uses as rpms and de-emphasise the FF autodowload -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From hp at redhat.com Wed Aug 22 22:39:45 2007 From: hp at redhat.com (Havoc Pennington) Date: Wed, 22 Aug 2007 18:39:45 -0400 Subject: PackageKit Misconceptions In-Reply-To: <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> Message-ID: <815098350708221539p2b6a263l766e1d2ec7ecc50@mail.gmail.com> On 8/22/07, Jeff Spaleta wrote: > On 8/22/07, Owen Taylor wrote: > > A) The information displayed to the user has been audited to be accurate > > You have a proposal on how to do this? I have grave concerns about > being legally allowed to do this in a centralize way as part of the > Fedora project. > The larger point about gpg import questions is really unchanged if there's no way to do a central authority. If we can't do a central authority, that just means you have to ask about "import GPG blah blah" and not "do you trust the Fedora Project?", and "import GPG blah blah" is NOT good enough / useful / a solution _at all_. The point is _not_ that a question about "import GPG" is suboptimal; the point is that it's useless and probably even actively harmful. At least that would be _my_ point, if it wasn't someone else's. ;-) Dialogs just are not security. If your software design is insecure if you don't ask, then your system is also insecure if you do ask, because as an empirical matter some huge percentage of people - including very tech-savvy people - will always click yes as a habit. Dialogs are for programmers to cover their own ass and blame the user. They do not do much at all to actually stop whether people become victims of security exploits, _in practice_. A dialog that's human readable (says "Fedora Project" not "GPG blah blah") _might_ be useful for a few more people than one with the GPG stuff, the non-human-readable one is useful for essentially nobody. But fundamentally it's still pretty weak security. A secure design either forbids unsigned stuff in a strong, almost-impossible-to-override way; or is secure despite unsigned stuff. Which in practice afaik means either a central signing authority (or at least some kind of web of trust or definition of which keys you trust), or you sandbox whatever is downloaded. No secure solution I've ever seen involves dialogs as a critical element. Havoc From blizzard at redhat.com Wed Aug 22 22:55:12 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 22 Aug 2007 18:55:12 -0400 Subject: notes from the aug 22nd 2007 fedora desktop sig meeting Message-ID: <1187823312.9211.9.camel@localhost.localdomain> Raw notes. Page lives here: http://fedoraproject.org/wiki/SIGs/Desktop/Meeting-20070822 Please add yourself if you were there and add yourself to the main desktop page (which is not complete yet) http://fedoraproject.org/wiki/Desktop = 2007 Aug 22 Desktop Meeting = == Present == * Chris Aillon * David Zeuthen * Christopher Blizzard * Ray Strode * Jesse Keating * Colin Walters * others (?) === Agenda === None posted. === Action Items === * Blizzard to add scope + goals to SIG in the wiki * Blizzard to clean up SIG and Desktop pages * David Zeuthen to clarify action items * Adam Jackson / Chris Aillon to finish bootchart package process + review * Colin Walters to work with David Zeuthen on clarifying the package set for the desktop spin and pushing into the livecd-creation repo === Previous Week's Action Items === * Adam was supposed to package up boot chart * In Progress - has packages and they are in review. Chris Aillon is reviewing. * David Zeuthen was supposed to work on the clock applet that changes time zones * In Progress * Blizzard was supposed to clean up the web pages and add scope + decision making to the SIG page * In Progress === Desktop page vs SIG Page === * Blizzard created the top level Desktop page in an attempt to make sure that things weren't buried * Confusing since we have shared information between the two * Need to consolidate and clarify that the Desktop page is the what and the SIG page is the who * Up to Blizzard to fix. === Where to send patches and changes? === * Avoid process, mailing list isn't an approval process * Just inform the mailing list if you can * Note that this project is for the "Fedora Desktop spin" which is not the normal Fedora spin. More freedom to make changes and set reasonable desktop defaults. Different than Fedora for servers. * Main get-fedora page will have to emphasize this * Probably won't include package forks but is mostly setting reasonable defaults * Will have to work with package maintainers to make sure that those defaults are at least available * Examples: * PolicyKit and sudo style activation of system services (no root password) * NetworkManager by default * Lots of fear of divergence but needs to balance with ability to take risks and experiment * Probably a lot of changes that we need for Fedora as a whole at some point * Will work with the board if we need package divergence and work through any possible trademark or project issues === Workflow model === * Walters: want to move away from small fiefdom model * Example: things that require a lot of changes all the way across the distribution like sudo style access require lots of small changes to a lot of packages so we can't just work in silos * Use a post with a patch for changes instead of just going through single bugs + owners * Want to avoid forking wherever possible * Try do do things in the post-install stage with defaults instead * Main points: encourage experimentation and move quickly? * David Zeuthen: Main point is to have defaults that are good for desktop that might not work well on servers * Walters: Main point is to make sure that the desktop folks are in control of the experience * Don't worry about package forking, if we have to worry about that we'll work with the board and others on that topic later === Last Week's Action Items === * David Zeuthen still working on time zone applet * Adam Jackson has packaged boot camp, Chris Aillon is reviewing (lots of discussion of details) * Blizzard did some work but not on goals + scope === Comps Location for Desktop Spin === * Desktop spin lives in the livecd-tools git repo right now * co-owned by David Zeuthen and Colin Walters * They will discuss what changes they want to make on the mailing list * "Low hanging fruit" thread was supposed to be the start of the changes but it got out of control pretty quickly * Jesse points out that there's only one week to feature freeze :) === Responsibility of fixes/changes in Desktop vs. Regular Spin? === * How do we track the difference? Something in /etc/fedora-release or /etc/fedora-spin? * Hard to diverge due to crappy tool set * Can't tell where bug reports come from * Lots and lots of discussion (ask the user, detect in bugzilla, write to a file, etc) * Have to move this to next week if that's possible === Big Root Password Discussion === * extra password that's not needed on a desktop system * want to move to a policykit based solution * discussion of sudo + policykit system would work === Next Week === * Follow up on action items * From Jesse: How to get rid of firstboot screens? From otaylor at redhat.com Wed Aug 22 23:01:54 2007 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 22 Aug 2007 19:01:54 -0400 Subject: PackageKit Misconceptions In-Reply-To: <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> Message-ID: <190e0dab0708221601q1088a6e2wc05776bb0c6f5b32@mail.gmail.com> On 8/22/07, Jeff Spaleta wrote: > On 8/22/07, Owen Taylor wrote: > > A) The information displayed to the user has been audited to be accurate > > You have a proposal on how to do this? I have grave concerns about > being legally allowed to do this in a centralize way as part of the > Fedora project. Now, I have no competence to address the legality, but there is a big difference between providing a listing of third party repositories as compared, to, when queried say "Yes, Joe Smith's Package Repository is in fact an accurate description of this .repo file" The latter can even be done without storing *any* information about Joe Smith's Package Repository on the Fedora repository by instead storing a GPG keyring of people trusted to do such audits and sign the information. > > B) We provide some sort of reputation system displayed right along > > with the question so that you have a basis for an informed decision > > Uhm... probably not possible. I seriously doubt that we could > officially host a ranking of 3rd party sources in fedora controlled > infrastructure. We go out of our way to not officially communicate > about 3rd party repos. I have a very hard time seeing how this is > going to be integrated into a Fedora experience with the Fedora > Project acting as the central broker of reputation. Well, there is one form of reputation system that I'm sure would pass muster ... a blacklist of known bad sites. But I'm pretty sure you can go further than that without running legal risks if you have no listing of sites and no "recommendation", and just display the data when the user is going to install the .repo file / GPG key. All you really need to store is: - Number of times the repo file / GPG key has been installed - Number of problem reports - Ability to click and view the problem reports So you wouldn't be endorsing Joe Smith's Package Repository at all, but if someone found a link to it, they'd be able to see the stats that 10,000 other people have installed the package repository, and 10 people have reported problems. People could draw their own conclusion from that whether it was a safe repository to install. Remember, we don't need to answer the question "what are cool repos to add", we just need to answer the question "is this repo that I'm trying to add safe or not". - Owen From jspaleta at gmail.com Wed Aug 22 23:06:45 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Aug 2007 15:06:45 -0800 Subject: PackageKit Misconceptions In-Reply-To: <815098350708221539p2b6a263l766e1d2ec7ecc50@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> <815098350708221539p2b6a263l766e1d2ec7ecc50@mail.gmail.com> Message-ID: <604aa7910708221606r76b489c1g41929e97f661e847@mail.gmail.com> On 8/22/07, Havoc Pennington wrote: > The larger point about gpg import questions is really unchanged if > there's no way to do a central authority. I don't disagree. But I'm not sure we have the freedom to centralize such an authority inside the fedora project, given my current understanding of how we are allowed to interact with 3rd party repositories. I'm concerned that legal will need to review any such plans. I also don't think we can realistically externalize such authority and expect such an external authority to play a central role out of the box. From jspaleta at gmail.com Wed Aug 22 23:36:05 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Aug 2007 15:36:05 -0800 Subject: PackageKit Misconceptions In-Reply-To: <190e0dab0708221601q1088a6e2wc05776bb0c6f5b32@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> <190e0dab0708221601q1088a6e2wc05776bb0c6f5b32@mail.gmail.com> Message-ID: <604aa7910708221636m60c19aa0m1f60cba4682c49af@mail.gmail.com> On 8/22/07, Owen Taylor wrote: > So you wouldn't be endorsing Joe Smith's Package Repository at all, Putting aside the debate of popularity != safety for the time being.... We don't have to "endorse" to run afoul of legal issues. Merely helping users compile a list of any 3rd party repositories is potentially off-limits. Can you point to anything we are doing right now, where we make any effort at all to comprehensively list 3rd party repositories inside the official fedora project space.. even in the wiki.. even without using urls? My understanding is that we aren't even allowed to do that. Even a simple list of repository entities, with absolutely no contextual information concern the quality or scope of their contents, may be beyond the bounds of what we are allowed to provide. Any reputation system inherently involves making such a list and then adding contextual information. "This repo exists" maybe a statement that is beyond what we are capable of saying in any official capacity. -jef"hopes we can implement this, so I can game the system and make my repository of deliberately malformed packages appear to be safe by installing 100,000 or so virtual machines and give them all unique smolt ids and have a bug tracker that reports back zero bugs found against all queries"spaleta From otaylor at redhat.com Wed Aug 22 23:53:58 2007 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 22 Aug 2007 19:53:58 -0400 Subject: PackageKit Misconceptions In-Reply-To: <604aa7910708221636m60c19aa0m1f60cba4682c49af@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> <190e0dab0708221601q1088a6e2wc05776bb0c6f5b32@mail.gmail.com> <604aa7910708221636m60c19aa0m1f60cba4682c49af@mail.gmail.com> Message-ID: <190e0dab0708221653g63938d31ybcf45ee934a00a63@mail.gmail.com> On 8/22/07, Jeff Spaleta wrote: > On 8/22/07, Owen Taylor wrote: > > So you wouldn't be endorsing Joe Smith's Package Repository at all, > > Putting aside the debate of popularity != safety for the time being.... > > We don't have to "endorse" to run afoul of legal issues. Merely > helping users compile a list of any 3rd party repositories is > potentially off-limits. > Can you point to anything we are doing right now, where we make any > effort at all to comprehensively list 3rd party repositories inside > the official fedora project space.. even in the wiki.. even without > using urls? My understanding is that we aren't even allowed to do > that. OK, so store everything indexed by one-way hash of a repo GUID, so there is no way of mapping back from what is on the server to the 3rd party repository at all, even if you have access to the raw data files on our server... I'm sure we can work with legal to come up with something acceptable. - Owen From jspaleta at gmail.com Thu Aug 23 00:52:10 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Aug 2007 16:52:10 -0800 Subject: PackageKit Misconceptions In-Reply-To: <190e0dab0708221653g63938d31ybcf45ee934a00a63@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> <190e0dab0708221601q1088a6e2wc05776bb0c6f5b32@mail.gmail.com> <604aa7910708221636m60c19aa0m1f60cba4682c49af@mail.gmail.com> <190e0dab0708221653g63938d31ybcf45ee934a00a63@mail.gmail.com> Message-ID: <604aa7910708221752m96a4982s9d8ffefeafb8e7ae@mail.gmail.com> On 8/22/07, Owen Taylor wrote: > I'm sure we can work with legal to come up with something acceptable. I hope so. I just want to make sure you guys don't go crazy on implementation mock-ups just to get your bubbles bursted by the non-technical constraints. End of the day reality: the gpg importation dialogs that we have are pretty meaninglist to self-admining users. Being able to offer some sort of measure of "trust" in the validity of repository keys would do a lot and would allow us to deny importation and redirect users to our authority site for an explanation of the denial. Though how we handle local network repositories that we can't act as an authority for...that's a tougher question. It's easy to forget that .edus and even .coms can and will have internal repositories that desktop installs will be encouraged to use. These repos are absolutely and utterly hidden from scrutiny from any public authority. I still think there are some inherent problems with reputation associated with any definition of "safety", but we've got months to argue over that if things come to that. -jef From walters at redhat.com Thu Aug 23 00:55:41 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 22 Aug 2007 20:55:41 -0400 Subject: PackageKit Misconceptions In-Reply-To: <604aa7910708221752m96a4982s9d8ffefeafb8e7ae@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> <190e0dab0708221601q1088a6e2wc05776bb0c6f5b32@mail.gmail.com> <604aa7910708221636m60c19aa0m1f60cba4682c49af@mail.gmail.com> <190e0dab0708221653g63938d31ybcf45ee934a00a63@mail.gmail.com> <604aa7910708221752m96a4982s9d8ffefeafb8e7ae@mail.gmail.com> Message-ID: On 8/22/07, Jeff Spaleta wrote: > > It's easy to forget that > .edus and even .coms can and will have internal repositories that > desktop installs will be encouraged to use. These repos are absolutely > and utterly hidden from scrutiny from any public authority. Yes, but those people will ensure that people using the systems have the requisite keys preinstalled. At least they will if they're at all sane. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Thu Aug 23 01:23:36 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 23 Aug 2007 02:23:36 +0100 Subject: PackageKit Misconceptions In-Reply-To: <604aa7910708221752m96a4982s9d8ffefeafb8e7ae@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> <190e0dab0708221601q1088a6e2wc05776bb0c6f5b32@mail.gmail.com> <604aa7910708221636m60c19aa0m1f60cba4682c49af@mail.gmail.com> <190e0dab0708221653g63938d31ybcf45ee934a00a63@mail.gmail.com> <604aa7910708221752m96a4982s9d8ffefeafb8e7ae@mail.gmail.com> Message-ID: <15e53e180708221823x2c591568j4bd982ce9daa533b@mail.gmail.com> On 23/08/07, Jeff Spaleta wrote: > On 8/22/07, Owen Taylor wrote: > > I'm sure we can work with legal to come up with something acceptable. > > I hope so. I just want to make sure you guys don't go crazy on > implementation mock-ups just to get your bubbles bursted by the > non-technical constraints. Ohh, it's entirely doable in the current PackageKit design, it's just an argument on whether it's a good idea to do so or not. What I'm currently thinking is: User installs livna/internal/freshrpms repo rpm User types in mplayer into application finder User clicks install PackageKit gets the GPG key message, and returns an error enum gpg-key-required and the description of the repo as the technical data. The install "fails" and a dialog is presented to the user. Then, as a seporate task the user can click on the button in the failure GUI and the GPG key can be imported (using PolicyKit as auth?). Then the install can be retried and should succeed. Sounds insane to me, but allows us to keep (and further improve) the GPG repo signed issue if we want to, or have to, keep it. Richard. From jspaleta at gmail.com Thu Aug 23 05:01:02 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Aug 2007 21:01:02 -0800 Subject: PackageKit Misconceptions In-Reply-To: References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> <190e0dab0708221601q1088a6e2wc05776bb0c6f5b32@mail.gmail.com> <604aa7910708221636m60c19aa0m1f60cba4682c49af@mail.gmail.com> <190e0dab0708221653g63938d31ybcf45ee934a00a63@mail.gmail.com> <604aa7910708221752m96a4982s9d8ffefeafb8e7ae@mail.gmail.com> Message-ID: <604aa7910708222201g3be95e30kfda7d66ae6b5f75d@mail.gmail.com> On 8/22/07, Colin Walters wrote: > Yes, but those people will ensure that people using the systems have the > requisite keys preinstalled. At least they will if they're at all sane. I think its comical to suggest that people who run repos inside large .edu networks, have the ability to ensure their userbase will have keys pre-installed. Don't neglect the hundreds of edu repos that exist just because Fedora can't see them. -jef"Go to the nearest college or university that as a Division 1 football team, and interact with a random sampling of first year students to re-calibrate your user expectations inside edu network firewalls."spaleta From nicu_fedora at nicubunu.ro Thu Aug 23 06:36:02 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 23 Aug 2007 09:36:02 +0300 Subject: Round 3 Default Artwork Decision In-Reply-To: References: <46CC9345.7090601@redhat.com> <1187813964.1994.12.camel@rousalka.dyndns.org> Message-ID: <46CD2AD2.8070709@nicubunu.ro> dragoran wrote: > > On 8/22/07, *Nicolas Mailhot* > Please check with the desktop group, I think at least some of those > won't be needed by the new F8 boot process > > > boot process wont change in f8 This seems correct: "Work on this has not yet begun" [1] and feature freeze is a few days away [1] - http://fedoraproject.org/wiki/Releases/FeatureBetterStartup -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From nicolas.mailhot at laposte.net Thu Aug 23 08:25:03 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 23 Aug 2007 10:25:03 +0200 (CEST) Subject: Round 3 Default Artwork Decision In-Reply-To: <46CD2AD2.8070709@nicubunu.ro> References: <46CC9345.7090601@redhat.com> <1187813964.1994.12.camel@rousalka.dyndns.org> <46CD2AD2.8070709@nicubunu.ro> Message-ID: <12291.192.54.193.51.1187857503.squirrel@rousalka.dyndns.org> Le Jeu 23 ao?t 2007 08:36, Nicu Buculei a ?crit : > dragoran wrote: >> >> On 8/22/07, *Nicolas Mailhot* > >> Please check with the desktop group, I think at least some of >> those >> won't be needed by the new F8 boot process >> >> >> boot process wont change in f8 > > This seems correct: "Work on this has not yet begun" [1] and feature > freeze is a few days away > > > [1] - http://fedoraproject.org/wiki/Releases/FeatureBetterStartup You're assuming the wiki is up to date :) -- Nicolas Mailhot From nicu_fedora at nicubunu.ro Thu Aug 23 08:37:55 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 23 Aug 2007 11:37:55 +0300 Subject: Round 3 Default Artwork Decision In-Reply-To: <12291.192.54.193.51.1187857503.squirrel@rousalka.dyndns.org> References: <46CC9345.7090601@redhat.com> <1187813964.1994.12.camel@rousalka.dyndns.org> <46CD2AD2.8070709@nicubunu.ro> <12291.192.54.193.51.1187857503.squirrel@rousalka.dyndns.org> Message-ID: <46CD4763.5000107@nicubunu.ro> Nicolas Mailhot wrote: > Le Jeu 23 ao?t 2007 08:36, Nicu Buculei a ?crit : >> This seems correct: "Work on this has not yet begun" [1] and feature >> freeze is a few days away >> >> >> [1] - http://fedoraproject.org/wiki/Releases/FeatureBetterStartup > > You're assuming the wiki is up to date :) I back that assumption on what I remember being discussed on various (desktop?) lists but I am too lazy to go and search -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From bnocera at redhat.com Thu Aug 23 08:53:00 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 23 Aug 2007 09:53:00 +0100 Subject: PackageKit Misconceptions In-Reply-To: References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> Message-ID: <1187859180.3208.145.camel@cookie.hadess.net> On Wed, 2007-08-22 at 13:55 -0400, Colin Walters wrote: > On 8/22/07, Jesse Keating wrote: > > There aren't requirements, however given that our software is > mirrored > around the world and our tools are made easy to make your own > Fedora, > it's possible that somebody could start handing out spoofed > Fedoras. > If the key you're asking to import says it's Fedora, but the > public key > servers don't match this key, that's a very quick indication > that you > should stop using the system as it's been compromised in some > way. > > Jean is a physics researcher at CERN. He installed Fedora on his > workstation because he's developing some parallel computation software > related to his hypothesis using MPI, and he likes Linux as a > development environment. He is helping to discover the fundamental > properties of the universe. > > > Jean is smarter than anyone posting in this thread. > > People keep making the assumption that reducing questions is designing > for "dumb" users. In fact, we're designing for users who have *more > important things to do*. > > We should make sure we're not stopping Jean in the middle of his work > with a question like "Do you trust this hex number?". It's not that > he couldn't answer it, but we certainly don't make it easy to do so > "correctly" (which I guess is browsing to pgp.mit.edu and manually > entering the hex number and making some sort of wild guess based on > other signatures). If which key is available as part of the metadata for the packages, we could flag the packages as being signed, but not verified in the UI. Some simple integration with seahorse could then help import specific keys from pgp.mit.edu, and for people to be able to verify the key before importing. From drago01 at gmail.com Thu Aug 23 09:53:23 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 23 Aug 2007 11:53:23 +0200 Subject: Round 3 Default Artwork Decision In-Reply-To: <12291.192.54.193.51.1187857503.squirrel@rousalka.dyndns.org> References: <46CC9345.7090601@redhat.com> <1187813964.1994.12.camel@rousalka.dyndns.org> <46CD2AD2.8070709@nicubunu.ro> <12291.192.54.193.51.1187857503.squirrel@rousalka.dyndns.org> Message-ID: <46CD5913.7070600@gmail.com> Nicolas Mailhot wrote: > Le Jeu 23 ao?t 2007 08:36, Nicu Buculei a ?crit : > >> dragoran wrote: >> >>> On 8/22/07, *Nicolas Mailhot* >> >>> Please check with the desktop group, I think at least some of >>> those >>> won't be needed by the new F8 boot process >>> >>> >>> boot process wont change in f8 >>> >> This seems correct: "Work on this has not yet begun" [1] and feature >> freeze is a few days away >> >> >> [1] - http://fedoraproject.org/wiki/Releases/FeatureBetterStartup >> > > You're assuming the wiki is up to date :) > > yes the kernel modesetting support is not done yet and this was required for this. From mikkel at infinity-ltd.com Thu Aug 23 15:16:08 2007 From: mikkel at infinity-ltd.com (Mikkel L. Ellertson) Date: Thu, 23 Aug 2007 10:16:08 -0500 Subject: PackageKit Misconceptions In-Reply-To: <604aa7910708221752m96a4982s9d8ffefeafb8e7ae@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> <190e0dab0708221601q1088a6e2wc05776bb0c6f5b32@mail.gmail.com> <604aa7910708221636m60c19aa0m1f60cba4682c49af@mail.gmail.com> <190e0dab0708221653g63938d31ybcf45ee934a00a63@mail.gmail.com> <604aa7910708221752m96a4982s9d8ffefeafb8e7ae@mail.gmail.com> Message-ID: <46CDA4B8.5040907@infinity-ltd.com> Jeff Spaleta wrote: > On 8/22/07, Owen Taylor wrote: >> I'm sure we can work with legal to come up with something acceptable. > > I hope so. I just want to make sure you guys don't go crazy on > implementation mock-ups just to get your bubbles bursted by the > non-technical constraints. > > End of the day reality: > the gpg importation dialogs that we have are pretty meaninglist to > self-admining users. Being able to offer some sort of measure of > "trust" in the validity of repository keys would do a lot and would > allow us to deny importation and redirect users to our authority site > for an explanation of the denial. > > Though how we handle local network repositories that we can't act as > an authority for...that's a tougher question. It's easy to forget that > .edus and even .coms can and will have internal repositories that > desktop installs will be encouraged to use. These repos are absolutely > and utterly hidden from scrutiny from any public authority. > > I still think there are some inherent problems with reputation > associated with any definition of "safety", but we've got months to > argue over that if things come to that. > > -jef > Dumb question - would it be possible to sign the gpg keys of the repos with the Fedora key, and then report the signature as part of the import dialog? (I know it can be done technically, but I am not sure how practical/legal it would be...) Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From sundaram at fedoraproject.org Thu Aug 23 15:37:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 23 Aug 2007 21:07:17 +0530 Subject: notes from the aug 22nd 2007 fedora desktop sig meeting In-Reply-To: <1187823312.9211.9.camel@localhost.localdomain> References: <1187823312.9211.9.camel@localhost.localdomain> Message-ID: <46CDA9AD.6080505@fedoraproject.org> Christopher Blizzard wrote: > Raw notes. Page lives here: > > http://fedoraproject.org/wiki/SIGs/Desktop/Meeting-20070822 > > Please add yourself if you were there and add yourself to the main > desktop page (which is not complete yet) > > http://fedoraproject.org/wiki/Desktop > > = 2007 Aug 22 Desktop Meeting = It would be nice if someone could post the raw logs from the past two meetings. Thanks. Rahul From rstrode at redhat.com Thu Aug 23 16:49:41 2007 From: rstrode at redhat.com (Ray Strode) Date: Thu, 23 Aug 2007 12:49:41 -0400 Subject: Round 3 Default Artwork Decision In-Reply-To: <46CD2AD2.8070709@nicubunu.ro> References: <46CC9345.7090601@redhat.com> <1187813964.1994.12.camel@rousalka.dyndns.org> <46CD2AD2.8070709@nicubunu.ro> Message-ID: <1187887781.2345.5.camel@halflap.boston.devel.redhat.com> Hi, On Thu, 2007-08-23 at 09:36 +0300, Nicu Buculei wrote: > dragoran wrote: > > > > On 8/22/07, *Nicolas Mailhot* > > > Please check with the desktop group, I think at least some of those > > won't be needed by the new F8 boot process > > > > > > boot process wont change in f8 > > This seems correct: "Work on this has not yet begun" [1] and feature > freeze is a few days away > > > [1] - http://fedoraproject.org/wiki/Releases/FeatureBetterStartup Just to give a status update... It's not that work hasn't begun, a lot of graphical boot up code has been written already. See http://blogs.gnome.org/halfline/2007/06/09/graphical-boot-up/ and the git repo here: http://cgit.freedesktop.org/~halfline/plymouth work has been shelved until kernel mode setting support gets better. When things pick back up again, though, we'd like to try to get a better big picture of what's needed in the entire boot process (investigate more than just "graphical bootup", but also boot speed, firstboot, etc, too). Anyway, none of it is really Fedora 8 material. --Ray From davidz at redhat.com Thu Aug 23 16:56:56 2007 From: davidz at redhat.com (David Zeuthen) Date: Thu, 23 Aug 2007 12:56:56 -0400 Subject: PackageKit Misconceptions In-Reply-To: <15e53e180708221823x2c591568j4bd982ce9daa533b@mail.gmail.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <1187805767.2903.75.camel@oneill.fubar.dk> <20070822141141.4ccdde10@mentok.boston.redhat.com> <190e0dab0708221147w3021125ejcfcdfe7ba909fb29@mail.gmail.com> <604aa7910708221423q7a720a2ah684306b26bc7305a@mail.gmail.com> <190e0dab0708221601q1088a6e2wc05776bb0c6f5b32@mail.gmail.com> <604aa7910708221636m60c19aa0m1f60cba4682c49af@mail.gmail.com> <190e0dab0708221653g63938d31ybcf45ee934a00a63@mail.gmail.com> <604aa7910708221752m96a4982s9d8ffefeafb8e7ae@mail.gmail.com> <15e53e180708221823x2c591568j4bd982ce9daa533b@mail.gmail.com> Message-ID: <1187888216.3301.7.camel@oneill.fubar.dk> On Thu, 2007-08-23 at 02:23 +0100, Richard Hughes wrote: > On 23/08/07, Jeff Spaleta wrote: > > On 8/22/07, Owen Taylor wrote: > > > I'm sure we can work with legal to come up with something acceptable. > > > > I hope so. I just want to make sure you guys don't go crazy on > > implementation mock-ups just to get your bubbles bursted by the > > non-technical constraints. > > Ohh, it's entirely doable in the current PackageKit design, it's just > an argument on whether it's a good idea to do so or not. > > What I'm currently thinking is: > > User installs livna/internal/freshrpms repo rpm > User types in mplayer into application finder > User clicks install > > PackageKit gets the GPG key message, and returns an error enum > gpg-key-required and the description of the repo as the technical > data. The install "fails" and a dialog is presented to the user. > > Then, as a seporate task the user can click on the button in the > failure GUI and the GPG key can be imported (using PolicyKit as > auth?). Then the install can be retried and should succeed. > > Sounds insane to me, but allows us to keep (and further improve) the > GPG repo signed issue if we want to, or have to, keep it. Sounds sane to me actually. Initially I'd just show the GPG key and name and link to a bunch of disclaimers/explanations; it will be pretty useless initially but on par with what yum / pirut does [1]. I like the idea that GPG importing is a separate application (but should still live in the PackageKit tarball/repository IMO); it makes it easier for contributors to hack on it to land some of the ideas about trust metrics etc. Regarding abstraction, does the other packaging formats and/or depsolvers work in a similar way? Something to think about. David [1] : http://www.pro-linux.de/berichte/jpgs/fc5-test2/fc5-pirut.png From jon.nettleton at gmail.com Fri Aug 24 15:19:21 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 24 Aug 2007 11:19:21 -0400 Subject: More low hanging fruit. Message-ID: Should the desktop release have X run on vt1 and a text console on vt2? I also don't see much reason to have more than that either. I probably wouldn't remove them from inittab just disable them in run level 5. Jon From rstrode at redhat.com Fri Aug 24 15:35:44 2007 From: rstrode at redhat.com (Ray Strode) Date: Fri, 24 Aug 2007 11:35:44 -0400 Subject: More low hanging fruit. In-Reply-To: References: Message-ID: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> Hi, On Fri, 2007-08-24 at 11:19 -0400, Jon Nettleton wrote: > Should the desktop release have X run on vt1 and a text console on vt2? > I also don't see much reason to have more than that either. I probably > wouldn't remove them from inittab just disable them in run level 5. Seems like a good idea to me. At a minimum we should get rid of the getty on tty1 so we don't have the brief "Login: " flash when the screen jumps from rhgb to gdm. --Ray From martin.sourada at seznam.cz Fri Aug 24 17:15:01 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 24 Aug 2007 19:15:01 +0200 Subject: Idea: easier transition for newcomers from other DEs/OSes Message-ID: <1187975701.9578.203.camel@pc-notebook> Hi, It's all about picking default settings new users wish. Imagine a user who is coming from Windows to Fedora, but he has no clue how linux works. It would greatly help him if the linux behaved to some extent similar to Windows - meaning applications look (themes), window's buttons layout (in this case same), menu layout, keyboard shortcuts etc. The same for users coming from Mac OS and for users used to Gnome and switching to KDE and opposite way. The idea is that user selects what he wants his desktop resemble, and then the usage of the desktop would be more intuitive to him. What would we need for that? 1. Check out, how much we can set up GNOME/KDE to look and behave like other DEs/OSes 2. If some of the stuff which makes this easier is available, but not in fedora, get it into repository 3. Write a utility that can change the DE's settings to what we have found in 1. 4. Integrate the utility into anaconda or first boot. The utility should be pretty straightforward - you will have a bunch of radio buttons captioned Windows 9x, Windows XP, Windows Vista, Mac OS X (dunno version differences though, might need more radio buttons for that one), GNOME, KDE (for how it should look like) and a two check boxes with simple description of GNOME and KDE (in the description should be noted primarily differences between those to, to ease selection to one who has no idea what GNOME/KDE is; for what will be used as 'backend'). Just a though... Your opinions? Is it even desirable? Does it make sense? Martin -------------- 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 david at lovesunix.net Fri Aug 24 17:37:54 2007 From: david at lovesunix.net (David Nielsen) Date: Fri, 24 Aug 2007 19:37:54 +0200 Subject: Idea: easier transition for newcomers from other DEs/OSes In-Reply-To: <1187975701.9578.203.camel@pc-notebook> References: <1187975701.9578.203.camel@pc-notebook> Message-ID: <1187977074.22980.12.camel@dawkins> fre, 24 08 2007 kl. 19:15 +0200, skrev Martin Sourada: > Hi, > > It's all about picking default settings new users wish. Imagine a user > who is coming from Windows to Fedora, but he has no clue how linux > works. It would greatly help him if the linux behaved to some extent > similar to Windows - meaning applications look (themes), window's > buttons layout (in this case same), menu layout, keyboard shortcuts etc. > The same for users coming from Mac OS and for users used to Gnome and > switching to KDE and opposite way. The idea is that user selects what he > wants his desktop resemble, and then the usage of the desktop would be > more intuitive to him. > > What would we need for that? > 1. Check out, how much we can set up GNOME/KDE to look and behave > like other DEs/OSes > 2. If some of the stuff which makes this easier is available, but > not in fedora, get it into repository > 3. Write a utility that can change the DE's settings to what we > have found in 1. > 4. Integrate the utility into anaconda or first boot. > > The utility should be pretty straightforward - you will have a bunch of > radio buttons captioned Windows 9x, Windows XP, Windows Vista, Mac OS X > (dunno version differences though, might need more radio buttons for > that one), GNOME, KDE (for how it should look like) and a two check > boxes with simple description of GNOME and KDE (in the description > should be noted primarily differences between those to, to ease > selection to one who has no idea what GNOME/KDE is; for what will be > used as 'backend'). > > Just a though... Your opinions? Is it even desirable? Does it make > sense? Chasing after a look and feel of a platform the user is already trying to escape, repeating the same visual mistakes as seen in those platform for familiarity' sake? Doesn't sound appealing to me, Fedora is it's own platform and we should work to make it the best one we are able to do by innovation not by emulation. If we don't do that Fedora will be nothing but a free version of Windows, it will look and feel the same but it will fundamentally not improve anything. Now I am all for looking at technologies like the migration tool Ubuntu has developed to ensure that all the users data and account settings are transferred safely so that mail will work and that picture of the family dog will still be on the background.. but please don't turn Fedora into a cheap knock-off, despite rumours to the contrary, people can believe it's not butter. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From ajackson at redhat.com Fri Aug 24 18:04:47 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 24 Aug 2007 14:04:47 -0400 Subject: Idea: easier transition for newcomers from other DEs/OSes In-Reply-To: <1187975701.9578.203.camel@pc-notebook> References: <1187975701.9578.203.camel@pc-notebook> Message-ID: <1187978687.1175.452.camel@localhost.localdomain> On Fri, 2007-08-24 at 19:15 +0200, Martin Sourada wrote: > Hi, > > It's all about picking default settings new users wish. Imagine a user > who is coming from Windows to Fedora, but he has no clue how linux > works. It would greatly help him if the linux behaved to some extent > similar to Windows - meaning applications look (themes), window's > buttons layout (in this case same), menu layout, keyboard shortcuts etc. > The same for users coming from Mac OS and for users used to Gnome and > switching to KDE and opposite way. The idea is that user selects what he > wants his desktop resemble, and then the usage of the desktop would be > more intuitive to him. Bzzt, logical fallacy. Read about the uncanny valley, then apply that lesson to your argument. Point for point emulation is not just technically infeasible, it's also a really really bad idea. - ajax From gmureddu at prodigy.net.mx Fri Aug 24 17:44:13 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Fri, 24 Aug 2007 13:44:13 -0400 Subject: More low hanging fruit. In-Reply-To: References: Message-ID: <46CF18ED.5060405@prodigy.net.mx> Jon Nettleton escribi?: > Should the desktop release have X run on vt1 and a text console on vt2? > I also don't see much reason to have more than that either. I probably > wouldn't remove them from inittab just disable them in run level 5. > > Jon > > I don't think that's a good idea... Like me, I know a bunch of users who do actually make use of the other VTs, making the default graphics VT VT1 seems like a good idea, but be done with the six text VTs doesn't, IMO look like such a good idea. From gmureddu at prodigy.net.mx Fri Aug 24 17:48:18 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Fri, 24 Aug 2007 13:48:18 -0400 Subject: More low hanging fruit. In-Reply-To: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> Message-ID: <46CF19E2.4090907@prodigy.net.mx> Ray Strode escribi?: > > Seems like a good idea to me. At a minimum we should get rid of the > getty on tty1 so we don't have the brief "Login: " flash when the screen > jumps from rhgb to gdm. > > --Ray > > When will Fedora drop RHGB once and for all? Seems all that's needed is already into the kernel or easily configured into it... Albeit the current mode setting is rather manual, but we could simply go with something standard such as 1024x768 at 32bpp, or is this value going to directly feed X resolution information? For in that case, why not make X and VT configuration part of either: boot loader (LiveCD) or Anaconda (DVD) for installation, just "like in the old days", I don't see why both resolution values have to be tied together or identical in any way... From drago01 at gmail.com Fri Aug 24 19:00:58 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 24 Aug 2007 21:00:58 +0200 Subject: More low hanging fruit. In-Reply-To: <46CF19E2.4090907@prodigy.net.mx> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> Message-ID: On 8/24/07, Gian Paolo Mureddu wrote: > > For in that case, why not make X > and VT configuration part of either: boot loader (LiveCD) or Anaconda > (DVD) for installation, just "like in the old days", NO! we have the autodetection in xorg which works just well .. why go back and ask the users useless questions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rstrode at redhat.com Fri Aug 24 19:02:01 2007 From: rstrode at redhat.com (Ray Strode) Date: Fri, 24 Aug 2007 15:02:01 -0400 Subject: More low hanging fruit. In-Reply-To: <46CF19E2.4090907@prodigy.net.mx> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> Message-ID: <1187982121.3054.35.camel@halflap.boston.devel.redhat.com> Hi, > When will Fedora drop RHGB once and for all? Not sure, Fedora 9, I think? > Seems all that's needed is > already into the kernel or easily configured into it... Albeit the > current mode setting is rather manual, but we could simply go with > something standard such as 1024x768 at 32bpp, or is this value going to > directly feed X resolution information? We're waiting on drm modesetting, which is more in line with what we need. (See the earlier low hanging fruit thread) --Ray From caillon at redhat.com Fri Aug 24 19:03:25 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 24 Aug 2007 15:03:25 -0400 Subject: More low hanging fruit. In-Reply-To: <46CF18ED.5060405@prodigy.net.mx> References: <46CF18ED.5060405@prodigy.net.mx> Message-ID: <46CF2B7D.8030404@redhat.com> Gian Paolo Mureddu wrote: > Jon Nettleton escribi?: >> Should the desktop release have X run on vt1 and a text console on vt2? >> I also don't see much reason to have more than that either. I probably >> wouldn't remove them from inittab just disable them in run level 5. >> >> Jon >> >> > I don't think that's a good idea... Like me, I know a bunch of users who > do actually make use of the other VTs, making the default graphics VT > VT1 seems like a good idea, but be done with the six text VTs doesn't, > IMO look like such a good idea. Bear in mind the scope. This is for a specialized Desktop spin, which is not the main Fedora distro. From rstrode at redhat.com Fri Aug 24 19:07:29 2007 From: rstrode at redhat.com (Ray Strode) Date: Fri, 24 Aug 2007 15:07:29 -0400 Subject: More low hanging fruit. In-Reply-To: <46CF18ED.5060405@prodigy.net.mx> References: <46CF18ED.5060405@prodigy.net.mx> Message-ID: <1187982449.3054.42.camel@halflap.boston.devel.redhat.com> Hi, > I don't think that's a good idea... Like me, I know a bunch of users who > do actually make use of the other VTs, making the default graphics VT > VT1 seems like a good idea, but be done with the six text VTs doesn't, > IMO look like such a good idea. Remember that this change is proposed for an experimental desktop specific spin. It doesn't seem unreasonable to me to target users who don't use multiple VTs. Keep in mind this is just configuration / default policy. If you want to try the experimental desktop spin, but would rather have more VTs, you can change /etc/inittab after the system is installed. On the other hand, you can also just use the normal Fedora spin, since we aren't talking about changing it. --Ray From jon.nettleton at gmail.com Fri Aug 24 19:12:32 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 24 Aug 2007 15:12:32 -0400 Subject: More low hanging fruit. In-Reply-To: <46CF19E2.4090907@prodigy.net.mx> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> Message-ID: On 8/24/07, Gian Paolo Mureddu wrote: > Ray Strode escribi?: > > > > Seems like a good idea to me. At a minimum we should get rid of the > > getty on tty1 so we don't have the brief "Login: " flash when the screen > > jumps from rhgb to gdm. > > > > --Ray > > > > > > When will Fedora drop RHGB once and for all? Seems all that's needed is > already into the kernel or easily configured into it... Albeit the > current mode setting is rather manual, but we could simply go with > something standard such as 1024x768 at 32bpp, or is this value going to > directly feed X resolution information? For in that case, why not make X > and VT configuration part of either: boot loader (LiveCD) or Anaconda > (DVD) for installation, just "like in the old days", I don't see why > both resolution values have to be tied together or identical in any way... > I almost have a working configuration that allows rhgb to use the gdm xserver. This means that once X starts ( even earlier than with rhgb now ) it is a seamless X transition all the way to login. I also have it doing cool things like instead of bouncing back to a VT for manual fsck it all happens right there in the rhgb vte screen. It isn't perfect yet but I am trying to get it usable enough to make it into Fedora 8 feature set. Jon From drago01 at gmail.com Fri Aug 24 19:32:53 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 24 Aug 2007 21:32:53 +0200 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> Message-ID: On 8/24/07, Jon Nettleton wrote: > > On 8/24/07, Gian Paolo Mureddu wrote: > > Ray Strode escribi?: > > > > > > Seems like a good idea to me. At a minimum we should get rid of the > > > getty on tty1 so we don't have the brief "Login: " flash when the > screen > > > jumps from rhgb to gdm. > > > > > > --Ray > > > > > > > > > > When will Fedora drop RHGB once and for all? Seems all that's needed is > > already into the kernel or easily configured into it... Albeit the > > current mode setting is rather manual, but we could simply go with > > something standard such as 1024x768 at 32bpp, or is this value going to > > directly feed X resolution information? For in that case, why not make X > > and VT configuration part of either: boot loader (LiveCD) or Anaconda > > (DVD) for installation, just "like in the old days", I don't see why > > both resolution values have to be tied together or identical in any > way... > > > I almost have a working configuration that allows rhgb to use the gdm > xserver. This > means that once X starts ( even earlier than with rhgb now ) it is a > seamless X transition > all the way to login. I also have it doing cool things like instead > of bouncing back to > a VT for manual fsck it all happens right there in the rhgb vte screen. > > It isn't perfect yet but I am trying to get it usable enough to make > it into Fedora 8 feature set. ok but feature freeze is in 4 days... will it be ready by then? -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at redhat.com Fri Aug 24 19:47:56 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 24 Aug 2007 15:47:56 -0400 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> Message-ID: On 8/24/07, Jon Nettleton wrote: > > > I almost have a working configuration that allows rhgb to use the gdm > xserver. This > means that once X starts ( even earlier than with rhgb now ) it is a > seamless X transition > all the way to login. I also have it doing cool things like instead > of bouncing back to > a VT for manual fsck it all happens right there in the rhgb vte screen. > > It isn't perfect yet but I am trying to get it usable enough to make > it into Fedora 8 feature set. That sounds awesome! I'm curious do you have a place where you're putting patches for your work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.nettleton at gmail.com Fri Aug 24 20:47:48 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 24 Aug 2007 16:47:48 -0400 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> Message-ID: On 8/24/07, dragoran wrote: > > > > On 8/24/07, Jon Nettleton wrote: > > On 8/24/07, Gian Paolo Mureddu wrote: > > > Ray Strode escribi?: > > > > > > > > Seems like a good idea to me. At a minimum we should get rid of the > > > > getty on tty1 so we don't have the brief "Login: " flash when the > screen > > > > jumps from rhgb to gdm. > > > > > > > > --Ray > > > > > > > > > > > > > > When will Fedora drop RHGB once and for all? Seems all that's needed is > > > already into the kernel or easily configured into it... Albeit the > > > current mode setting is rather manual, but we could simply go with > > > something standard such as 1024x768 at 32bpp, or is this value going to > > > directly feed X resolution information? For in that case, why not make X > > > and VT configuration part of either: boot loader (LiveCD) or Anaconda > > > (DVD) for installation, just "like in the old days", I don't see why > > > both resolution values have to be tied together or identical in any > way... > > > > > I almost have a working configuration that allows rhgb to use the gdm > > xserver. This > > means that once X starts ( even earlier than with rhgb now ) it is a > > seamless X transition > > all the way to login. I also have it doing cool things like instead > > of bouncing back to > > a VT for manual fsck it all happens right there in the rhgb vte screen. > > > > It isn't perfect yet but I am trying to get it usable enough to make > > it into Fedora 8 feature set. > > ok but feature freeze is in 4 days... will it be ready by then? > I think I got over the last major hurdle this morning so hopefully. From jon.nettleton at gmail.com Fri Aug 24 20:49:31 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 24 Aug 2007 16:49:31 -0400 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> Message-ID: On 8/24/07, Colin Walters wrote: > On 8/24/07, Jon Nettleton wrote: > > > > I almost have a working configuration that allows rhgb to use the gdm > > xserver. This > > means that once X starts ( even earlier than with rhgb now ) it is a > > seamless X transition > > all the way to login. I also have it doing cool things like instead > > of bouncing back to > > a VT for manual fsck it all happens right there in the rhgb vte screen. > > > > It isn't perfect yet but I am trying to get it usable enough to make > > it into Fedora 8 feature set. > > > That sounds awesome! I'm curious do you have a place where you're putting > patches for your work? > > I haven't released any official patches. I hope to finish the last bits tonight to make it publicly digestable, and enough to get it in for feature freeze. Then it will still need some debugging and such. It will be close, but I have high hopes right now. Jon From martin.sourada at seznam.cz Fri Aug 24 21:18:10 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 24 Aug 2007 23:18:10 +0200 Subject: Idea: easier transition for newcomers from other DEs/OSes In-Reply-To: <364d303b0708241228n12ca0343ydda41aef2b8e8800@mail.gmail.com> References: <1187975701.9578.203.camel@pc-notebook> <1187978687.1175.452.camel@localhost.localdomain> <364d303b0708241228n12ca0343ydda41aef2b8e8800@mail.gmail.com> Message-ID: <1187990290.9578.217.camel@pc-notebook> On Fri, 2007-08-24 at 21:28 +0200, Christopher Brown wrote: > On 24/08/07, Adam Jackson wrote: > On Fri, 2007-08-24 at 19:15 +0200, Martin Sourada wrote: > > Hi, > > > > It's all about picking default settings new users wish. > Imagine a user > > who is coming from Windows to Fedora, but he has no clue how > linux > > works. It would greatly help him if the linux behaved to > some extent > > similar to Windows - meaning applications look (themes), > window's > > buttons layout (in this case same), menu layout, keyboard > shortcuts etc. > > The same for users coming from Mac OS and for users used to > Gnome and > > switching to KDE and opposite way. The idea is that user > selects what he > > wants his desktop resemble, and then the usage of the > desktop would be > > more intuitive to him. > > Bzzt, logical fallacy. Read about the uncanny valley, then > apply that > lesson to your argument. Point for point emulation is not > just > technically infeasible, it's also a really really bad idea. > > I agree. As an aside, I found the uncanny valley article on wikipedia > fascinating. > > http://en.wikipedia.org/wiki/Uncanny_Valley > > if you're interested. However much you skin over GNOME or KDE to make > them look like inferior OS's with greater market penetration, it > really is pretty pointless. This creates restrictions on UI design and > people waste time developing like-for-like applications simply in > order to mimic The Control Panel or My Network Places. > System>Administration or Places>Network is faster and simpler and > after is easily picked up. I have yet to introduce anyone to GNOME and > they have failed to grasp the new layout - quite the reverse - the > simplicity is often seen as a key benefit. > > Cheers > Chris > -- > http://www.chruz.com > -- Ok, I had a sneaky feeling that it is against the philosophy, but wanted to mention it nevertheless. I wasn't talking about emulation (even though it might look so), I was talking about making the process of transitioning to other system easier. I use gnome, I like almost everything about it, but I am not the target audience here. Let's say it this way, comparing KDE and GNOME. You are happy GNOME user but want to try KDE, for whatever reason, so you'd actually like it to behave like you are used to (to certain extent). Like having two panels, three menus, similar looking widget set, same keyboard shortcuts. Nothing more, the applications would still be KDE, the kontrol center still be from KDE, etc. More generally I am talking about a utility that could ease the job of doing this. You can set pretty much in today's gnome or kde to be it more friendly to users used to something different, but it'll still be KDE and GNOME. I'd like those users to have easy utility, to ease their start - i.e. to set for them the basic things, so that they will both learn new behaviour, but also use some of the already learnt. It would be maybe even more appreciated by dual booters... And I was talking about CHOICE. If user wants why not help him. If he wants to try GNOME with all its defaults, let him do that as well. But anyway, you seem to be against that, so I will not pursue it further. It is probably a bad idea (and after reading the wikipedia article about the uncanny valley it seems even worse than that)... Martin -------------- 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 gmureddu at prodigy.net.mx Fri Aug 24 20:18:37 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Fri, 24 Aug 2007 16:18:37 -0400 Subject: More low hanging fruit. In-Reply-To: <46CF2B7D.8030404@redhat.com> References: <46CF18ED.5060405@prodigy.net.mx> <46CF2B7D.8030404@redhat.com> Message-ID: <46CF3D1D.7000200@prodigy.net.mx> Christopher Aillon escribi?: > > Bear in mind the scope. This is for a specialized Desktop spin, which > is not the main Fedora distro. > Ahhh, Ok, I was starting to worry that would affect the bulk of Fedora. From overholt at redhat.com Fri Aug 24 21:21:38 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 24 Aug 2007 17:21:38 -0400 Subject: Desktop spin: Java browser plugin Message-ID: <20070824212137.GC10186@redhat.com> Hi, With IcedTea set to be in F8, should we look at including the java browser plugin in the desktop spin by default? Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Fri Aug 24 21:28:20 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 24 Aug 2007 23:28:20 +0200 Subject: Desktop spin: Java browser plugin In-Reply-To: <20070824212137.GC10186@redhat.com> References: <20070824212137.GC10186@redhat.com> Message-ID: On 8/24/07, Andrew Overholt wrote: > > Hi, > > With IcedTea set to be in F8, should we look at including the java > browser plugin in the desktop spin by default? I don't see a reaso not to do so +1 from me... but how much space will icedtea take on the medium? -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at redhat.com Fri Aug 24 21:28:26 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 24 Aug 2007 17:28:26 -0400 Subject: Desktop spin: Java browser plugin In-Reply-To: <20070824212137.GC10186@redhat.com> References: <20070824212137.GC10186@redhat.com> Message-ID: On 8/24/07, Andrew Overholt wrote: > > Hi, > > With IcedTea set to be in F8, should we look at including the java > browser plugin in the desktop spin by default? I think that makes sense, but a lot is going to come down to space. What packages give me the plugin? -------------- next part -------------- An HTML attachment was scrubbed... URL: From overholt at redhat.com Fri Aug 24 21:29:43 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 24 Aug 2007 17:29:43 -0400 Subject: Desktop spin: Java browser plugin In-Reply-To: References: <20070824212137.GC10186@redhat.com> Message-ID: <20070824212943.GD10186@redhat.com> * Colin Walters [2007-08-24 17:28]: > On 8/24/07, Andrew Overholt wrote: > > With IcedTea set to be in F8, should we look at including the java > browser plugin in the desktop spin by default? > > > I think that makes sense, but a lot is going to come down to space. What > packages give me the plugin? java-1.7.0-icedtea-plugin. Space considerations understood. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Fri Aug 24 21:32:05 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 24 Aug 2007 23:32:05 +0200 Subject: Desktop spin: Java browser plugin In-Reply-To: <20070824212943.GD10186@redhat.com> References: <20070824212137.GC10186@redhat.com> <20070824212943.GD10186@redhat.com> Message-ID: On 8/24/07, Andrew Overholt wrote: > > * Colin Walters [2007-08-24 17:28]: > > On 8/24/07, Andrew Overholt wrote: > > > > With IcedTea set to be in F8, should we look at including the java > > browser plugin in the desktop spin by default? > > > > > > I think that makes sense, but a lot is going to come down to space. > What > > packages give me the plugin? > > java-1.7.0-icedtea-plugin. Space considerations understood. can we enable it for the default fedora install? (non live installation) we are using a dvd anyway so I doubt space would be a issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: From overholt at redhat.com Fri Aug 24 21:34:08 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 24 Aug 2007 17:34:08 -0400 Subject: Desktop spin: Java browser plugin In-Reply-To: References: <20070824212137.GC10186@redhat.com> <20070824212943.GD10186@redhat.com> Message-ID: <20070824213408.GE10186@redhat.com> * dragoran [2007-08-24 17:32]: > > > On 8/24/07, Andrew Overholt wrote: > > * Colin Walters [2007-08-24 17:28]: > > On 8/24/07, Andrew Overholt wrote: > > > > With IcedTea set to be in F8, should we look at including the java > > browser plugin in the desktop spin by default? > > > > > > I think that makes sense, but a lot is going to come down to space. > What > > packages give me the plugin? > > java-1.7.0-icedtea-plugin. Space considerations understood. > > > can we enable it for the default fedora install? (non live installation) > we are using a dvd anyway so I doubt space would be a issue. Sure. And I've CC'd Tom Fitzsimmons to tell us about the security situation surrounding it. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rstrode at redhat.com Fri Aug 24 21:33:56 2007 From: rstrode at redhat.com (Ray Strode) Date: Fri, 24 Aug 2007 17:33:56 -0400 Subject: Desktop spin: Java browser plugin In-Reply-To: <20070824212137.GC10186@redhat.com> References: <20070824212137.GC10186@redhat.com> Message-ID: <1187991236.3054.44.camel@halflap.boston.devel.redhat.com> Hi, > With IcedTea set to be in F8, should we look at including the java > browser plugin in the desktop spin by default? A working java plugin out of the box makes sense for mainline fedora too... --Ray From walters at redhat.com Fri Aug 24 21:59:51 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 24 Aug 2007 17:59:51 -0400 Subject: Desktop spin: Java browser plugin In-Reply-To: <1187991236.3054.44.camel@halflap.boston.devel.redhat.com> References: <20070824212137.GC10186@redhat.com> <1187991236.3054.44.camel@halflap.boston.devel.redhat.com> Message-ID: On 8/24/07, Ray Strode wrote: > > Hi, > > > With IcedTea set to be in F8, should we look at including the java > > browser plugin in the desktop spin by default? > A working java plugin out of the box makes sense for mainline fedora > too... Definitely - Andrew what you should do as I understand things is to get this file changed: http://cvs.fedoraproject.org/viewcvs/comps/comps-f8.xml.in?rev=1.71&view=log Just stick it in graphical-internet? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Fri Aug 24 22:15:58 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 24 Aug 2007 17:15:58 -0500 Subject: More low hanging fruit. In-Reply-To: <46CF19E2.4090907@prodigy.net.mx> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> Message-ID: <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> On 8/24/07, Gian Paolo Mureddu wrote: > Ray Strode escribi?: > > > > Seems like a good idea to me. At a minimum we should get rid of the > > getty on tty1 so we don't have the brief "Login: " flash when the screen > > jumps from rhgb to gdm. > > > > --Ray > > > > > > When will Fedora drop RHGB once and for all? Is there a problem with RHGB? I haven't heard of one in the chatrooms or mailing list. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From pemboa at gmail.com Fri Aug 24 22:18:03 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 24 Aug 2007 17:18:03 -0500 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> Message-ID: <16de708d0708241518n329c6544h203f9ba02a832ef7@mail.gmail.com> On 8/24/07, dragoran wrote: > > > On 8/24/07, Gian Paolo Mureddu wrote: > > For in that case, why not make X > > and VT configuration part of either: boot loader (LiveCD) or Anaconda > > (DVD) for installation, just "like in the old days", > > NO! > we have the autodetection in xorg which works just well .. why go back and > ask the users useless questions? Since this autodetection has been put in place, I have had to manually set my Mode every Fedora install. It has never guessed correctly on any machine I have installed it on. I don't complain about it since I can only assume it works well for someone out there. But it doesn't work "just well" -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jon.nettleton at gmail.com Fri Aug 24 22:31:19 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 24 Aug 2007 18:31:19 -0400 Subject: More low hanging fruit. In-Reply-To: <16de708d0708241518n329c6544h203f9ba02a832ef7@mail.gmail.com> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241518n329c6544h203f9ba02a832ef7@mail.gmail.com> Message-ID: On 8/24/07, Arthur Pemberton wrote: > On 8/24/07, dragoran wrote: > > > > > > On 8/24/07, Gian Paolo Mureddu wrote: > > > For in that case, why not make X > > > and VT configuration part of either: boot loader (LiveCD) or Anaconda > > > (DVD) for installation, just "like in the old days", > > > > NO! > > we have the autodetection in xorg which works just well .. why go back and > > ask the users useless questions? > > > Since this autodetection has been put in place, I have had to manually > set my Mode every Fedora install. It has never guessed correctly on > any machine I have installed it on. I don't complain about it since I > can only assume it works well for someone out there. But it doesn't > work "just well" > Do you have a bugzilla to point us to? Are these all using the same hardware? I know I have one LCD panel that no matter what chipset I plug it into it doesn't work. I have dumped the info and the EDID data is junk. Jon From overholt at redhat.com Fri Aug 24 22:26:53 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 24 Aug 2007 18:26:53 -0400 Subject: Desktop spin: Java browser plugin In-Reply-To: References: <20070824212137.GC10186@redhat.com> <1187991236.3054.44.camel@halflap.boston.devel.redhat.com> Message-ID: <20070824222653.GB26551@redhat.com> * Colin Walters [2007-08-24 17:59]: > On 8/24/07, Ray Strode wrote: > > Hi, > > > With IcedTea set to be in F8, should we look at including the java > > browser plugin in the desktop spin by default? > A working java plugin out of the box makes sense for mainline fedora > too... > > > Definitely - Andrew what you should do as I understand things is to get this > file changed: > http://cvs.fedoraproject.org/viewcvs/comps/comps-f8.xml.in?rev=1.71&view=log > Just stick it in graphical-internet? Yup, I was just mucking with Eclipse stuff in comps yesterday. Either Tom or I will make sure it gets in. Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Fri Aug 24 23:02:49 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 25 Aug 2007 01:02:49 +0200 Subject: More low hanging fruit. In-Reply-To: <16de708d0708241518n329c6544h203f9ba02a832ef7@mail.gmail.com> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241518n329c6544h203f9ba02a832ef7@mail.gmail.com> Message-ID: On 8/25/07, Arthur Pemberton wrote: > > On 8/24/07, dragoran wrote: > > > > > > On 8/24/07, Gian Paolo Mureddu wrote: > > > For in that case, why not make X > > > and VT configuration part of either: boot loader (LiveCD) or Anaconda > > > (DVD) for installation, just "like in the old days", > > > > NO! > > we have the autodetection in xorg which works just well .. why go back > and > > ask the users useless questions? > > > Since this autodetection has been put in place, I have had to manually > set my Mode every Fedora install. It has never guessed correctly on > any machine I have installed it on. I don't complain about it since I > can only assume it works well for someone out there. But it doesn't > work "just well" ok let me correct myself : "it works well aslong as your display does not return crap (dcc/edid info)" -------------- next part -------------- An HTML attachment was scrubbed... URL: From caillon at redhat.com Fri Aug 24 23:58:17 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 24 Aug 2007 19:58:17 -0400 Subject: More low hanging fruit. In-Reply-To: <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> Message-ID: <46CF7099.4010104@redhat.com> Arthur Pemberton wrote: > Is there a problem with RHGB? I haven't heard of one in the chatrooms > or mailing list. The main problem is that it starts an X server. When rhgb ends, its X server shuts down, and then a second X server is spawned for the user to log in with. That, and rhgb was designed to hide all the spew you get when you start up, but it doesn't because of all the spew that pops up before rhgb ever loads. Oh and then there's the "can't start eth0, network start failed" issue which makes you see most of the spew anyway on laptops. It's pretty much useless. From jon.nettleton at gmail.com Sat Aug 25 00:29:25 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 24 Aug 2007 20:29:25 -0400 Subject: More low hanging fruit. In-Reply-To: <46CF7099.4010104@redhat.com> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> Message-ID: On 8/24/07, Christopher Aillon wrote: > Arthur Pemberton wrote: > > Is there a problem with RHGB? I haven't heard of one in the chatrooms > > or mailing list. > > The main problem is that it starts an X server. When rhgb ends, its X > server shuts down, and then a second X server is spawned for the user to > log in with. I am working on this. Hopefully we will have only 1 Xserver running from boot to desktop. > That, and rhgb was designed to hide all the spew you get when you start > up, but it doesn't because of all the spew that pops up before rhgb ever > loads. Oh and then there's the "can't start eth0, network start failed" > issue which makes you see most of the spew anyway on laptops. It's > pretty much useless. > If you don't want to see this message why don't you disable eth0 from coming up on boot? This problem really has nothing to do with rhgb. Instead of complaining why not suggest what you would like to see. Jon From tiagomatos at gmail.com Sat Aug 25 00:50:36 2007 From: tiagomatos at gmail.com (Rui Tiago =?ISO-8859-1?Q?Ca=E7=E3o?= Matos) Date: Sat, 25 Aug 2007 01:50:36 +0100 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> Message-ID: <1188003036.3016.19.camel@hive> On Sex, 2007-08-24 at 20:29 -0400, Jon Nettleton wrote: > If you don't want to see this message why don't you disable eth0 from > coming up on boot? This problem really has nothing to do with rhgb. > > Instead of complaining why not suggest what you would like to see. Personally I'd prefer to not have time to see nothing. Boot should be as fast as possible: Power On -> BIOS output -> Nice image/color/gradient/whatever -> GDM ^ ^ Inevitable on x86 Realistically shouldn't take more than 20s. The point is, for a desktop spin there is nothing to show until GDM. Network management should be done by NM and pretty much everything else should be started on demand by D-Bus. *Reality check*: I know this won't happen for F8 but let's try for F9 :-) Rui -------------- 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 caillon at redhat.com Sat Aug 25 01:05:13 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 24 Aug 2007 21:05:13 -0400 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> Message-ID: <46CF8049.9060500@redhat.com> Jon Nettleton wrote: > If you don't want to see this message why don't you disable eth0 from > coming up on boot? This problem really has nothing to do with rhgb. Or I could just stop booting the machine to not see debug messages at bootup! Seriously, do you really expect the average user to do that just because of a bug[1] in rhgb? [1] The bug is that as soon as anything goes wrong, regardless of how critical it is, it starts dumping stuff out. See how e.g. MacOSX handles this: it just doesn't show the user anything if it's not critical, but it does log to /var/log/messages. Can't get wired because we're a laptop? NOT CARE. From jon.nettleton at gmail.com Sat Aug 25 01:19:26 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 24 Aug 2007 21:19:26 -0400 Subject: More low hanging fruit. In-Reply-To: <1188003036.3016.19.camel@hive> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <1188003036.3016.19.camel@hive> Message-ID: On 8/24/07, Rui Tiago Ca??o Matos wrote: > On Sex, 2007-08-24 at 20:29 -0400, Jon Nettleton wrote: > > If you don't want to see this message why don't you disable eth0 from > > coming up on boot? This problem really has nothing to do with rhgb. > > > > Instead of complaining why not suggest what you would like to see. > > Personally I'd prefer to not have time to see nothing. Boot should be as > fast as possible: > > Power On -> BIOS output -> Nice image/color/gradient/whatever -> GDM > ^ ^ > Inevitable on x86 Realistically shouldn't take more than 20s. > > The point is, for a desktop spin there is nothing to show until GDM. > Network management should be done by NM and pretty much everything else > should be started on demand by D-Bus. > > *Reality check*: I know this won't happen for F8 but let's try for > F9 :-) > Well with a vesa framebuffer I have. Power On -> BIOS output -> TUX vesa fb and 3 lines of text -> rhgb starts and runs -> GDM The whole process takes 40 seconds with BIOS and hitting enter at the grub screen. Your reality check is really spoiled by the fact that bios -> nash -> udev is 25 seconds. That is with high IO also. The work I have done has broken start_udev into two parts that the first creating static devices that Xorg needs to detect basic devices. Then the automatic detection of devices comes later. start_udev is about 5.5 secs by itself, when I break it up it is about 1.3 seconds and 4.5 seconds. The overhead of the second detection is hidden by the fact the gui is running instead of just sitting there. We will keep plugging away. If you truly want 20 seconds you should get on the ACPI mailing list and get suspend and hibernate working on your machine. Jon From jon.nettleton at gmail.com Sat Aug 25 01:26:01 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 24 Aug 2007 21:26:01 -0400 Subject: More low hanging fruit. In-Reply-To: <46CF8049.9060500@redhat.com> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <46CF8049.9060500@redhat.com> Message-ID: On 8/24/07, Christopher Aillon wrote: > Jon Nettleton wrote: > > If you don't want to see this message why don't you disable eth0 from > > coming up on boot? This problem really has nothing to do with rhgb. > > Or I could just stop booting the machine to not see debug messages at > bootup! > > Seriously, do you really expect the average user to do that just because > of a bug[1] in rhgb? > > [1] The bug is that as soon as anything goes wrong, regardless of how > critical it is, it starts dumping stuff out. See how e.g. MacOSX > handles this: it just doesn't show the user anything if it's not > critical, but it does log to /var/log/messages. Can't get wired because > we're a laptop? NOT CARE. Much better. So instead of dropping open the terminal you would rather have the spinner icon turn to a spinning yield icon or something. I can't say that will happen for Fedora 8 but I can see where for a desktop spin that could be doable. Thanks Jon From tiagomatos at gmail.com Sat Aug 25 23:23:55 2007 From: tiagomatos at gmail.com (Rui Tiago =?ISO-8859-1?Q?Ca=E7=E3o?= Matos) Date: Sun, 26 Aug 2007 00:23:55 +0100 Subject: low-hanging fruit In-Reply-To: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> Message-ID: <1188084235.3052.2.camel@hive> On Qua, 2007-08-15 at 15:56 -0400, Matthias Clasen wrote: > As discussed in the meeting, here is my personal > "laundry list" of low-hanging fruit. Note that some of > these are being worked on for F8 anyway. [snip sensible list of low-hanging fruit] I'd like to add another one: * get rid of the forced filesystem check every 26th mount. Rui -------------- 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 jon.nettleton at gmail.com Sat Aug 25 23:44:43 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Sat, 25 Aug 2007 19:44:43 -0400 Subject: low-hanging fruit In-Reply-To: <1188084235.3052.2.camel@hive> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> Message-ID: On 8/25/07, Rui Tiago Ca??o Matos wrote: > On Qua, 2007-08-15 at 15:56 -0400, Matthias Clasen wrote: > > As discussed in the meeting, here is my personal > > "laundry list" of low-hanging fruit. Note that some of > > these are being worked on for F8 anyway. > > [snip sensible list of low-hanging fruit] > > I'd like to add another one: > > * get rid of the forced filesystem check every 26th mount. > I agree. This is especially painful on machines with filesystems large filesystems. For a desktop spin it would probably be better to do this in user-space. Remind the user every so many days that they should schedule a disk check on next reboot, then give them an okay or remind me later button. Of course that is the "old busted" method. The new hotness will be when we can switch user-space to run off a temporary snapshot and check the filesystem with the system running. Always something to look forward to. Jon From sundaram at fedoraproject.org Sun Aug 26 00:25:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 26 Aug 2007 05:55:50 +0530 Subject: low-hanging fruit In-Reply-To: <46C5488E.7020500@nicubunu.ro> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C5488E.7020500@nicubunu.ro> Message-ID: <46D0C88E.1000709@fedoraproject.org> Nicu Buculei wrote: > Matthias Clasen wrote: >> As discussed in the meeting, here is my personal "laundry list" of >> low-hanging fruit. Note that some of >> these are being worked on for F8 anyway. > > I think I can propose another item: take a lesson from ccLiveContent and > include a little free multimedia content (free as in CC-BY-SA) in the > default install to show the user the multimedia capabilities. > This can be 2 or 3 songs in Ogg Vorbis format and 1 or 2 videos in Ogg > Theora. It does not matter *what* the content it, the videos may be RH > commercials, interviews with OLPC developers, FUDcon footage, whatever > as long as is shiny and can be played right away. This might be appropriate. http://www.youtube.com/watch?v=mhRzkGL82os Ogg version available under creative common share alike license. Comments? Rahul From gmureddu at prodigy.net.mx Sun Aug 26 03:37:07 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Sat, 25 Aug 2007 23:37:07 -0400 Subject: low-hanging fruit In-Reply-To: <1188084235.3052.2.camel@hive> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> Message-ID: <46D0F563.60904@prodigy.net.mx> Rui Tiago Ca??o Matos escribi?: > On Qua, 2007-08-15 at 15:56 -0400, Matthias Clasen wrote: > >> As discussed in the meeting, here is my personal >> "laundry list" of low-hanging fruit. Note that some of >> these are being worked on for F8 anyway. >> > > [snip sensible list of low-hanging fruit] > > I'd like to add another one: > > * get rid of the forced filesystem check every 26th mount. > > Rui > > Never heard of "tune2fs"? Just use it to set the mount count higher, `man tune2fs` From mclasen at redhat.com Sun Aug 26 04:58:04 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 26 Aug 2007 00:58:04 -0400 Subject: low-hanging fruit In-Reply-To: <1187374322.1161.39.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> <1187299998.3788.79.camel@oneill.fubar.dk> <46C5D50A.9060109@redhat.com> <46C5D953.1080301@redhat.com> <1187374322.1161.39.camel@localhost.localdomain> Message-ID: <1188104284.4266.9.camel@localhost.localdomain> On Fri, 2007-08-17 at 14:11 -0400, Matthias Clasen wrote: > > Yeah, doing a "lauch preferred browser/mail client/terminal" applet should > take ~20 lines of non-boilerplate code... > Turns out it took a bit more than 20 lines, but I ended up taking a different approach to implementing this anyway. The attached panel patch does 3 things: - let the launcher properties dialog handle selected desktop files sensibly - make the panel optionally use file monitoring for desktop files backing launchers - add some code that maintains preferred-web-browser.desktop and preferred-mail-reader.desktop and keeps them in sync with the corresponding gconf keys. The first two parts make sense independently of preferred apps; the third one should maybe live somewhere else, e.g. gnome-settings-daemon. Using this patch, we can have nicely updating launchers with correct icons for the preferred web and mail apps. Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: launcher-desktop-file-improvements.patch Type: text/x-patch Size: 18281 bytes Desc: not available URL: From sundaram at fedoraproject.org Sun Aug 26 04:59:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 26 Aug 2007 10:29:14 +0530 Subject: low-hanging fruit In-Reply-To: <1188104284.4266.9.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> <1187299998.3788.79.camel@oneill.fubar.dk> <46C5D50A.9060109@redhat.com> <46C5D953.1080301@redhat.com> <1187374322.1161.39.camel@localhost.localdomain> <1188104284.4266.9.camel@localhost.localdomain> Message-ID: <46D108A2.3050608@fedoraproject.org> Matthias Clasen wrote: > > - make the panel optionally use file monitoring for desktop files > backing launchers > Would this automatically remove the panel icons if the apps were uninstalled? > - add some code that maintains preferred-web-browser.desktop and > preferred-mail-reader.desktop and keeps them in sync with the > corresponding gconf keys. Does it automatically change the icons? Rahul From sundaram at fedoraproject.org Sun Aug 26 05:00:01 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 26 Aug 2007 10:30:01 +0530 Subject: low-hanging fruit In-Reply-To: <46D0F563.60904@prodigy.net.mx> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> <46D0F563.60904@prodigy.net.mx> Message-ID: <46D108D1.9070605@fedoraproject.org> Gian Paolo Mureddu wrote: > Never heard of "tune2fs"? Just use it to set the mount count higher, > `man tune2fs` Non-technical users or even many technical ones won't know about these options. Again, we are talking about the desktop spin here. Rahul From jon.nettleton at gmail.com Sun Aug 26 05:17:43 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Sun, 26 Aug 2007 01:17:43 -0400 Subject: low-hanging fruit In-Reply-To: <46D0F563.60904@prodigy.net.mx> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> <46D0F563.60904@prodigy.net.mx> Message-ID: On 8/25/07, Gian Paolo Mureddu wrote: > Rui Tiago Ca??o Matos escribi?: > > On Qua, 2007-08-15 at 15:56 -0400, Matthias Clasen wrote: > > > >> As discussed in the meeting, here is my personal > >> "laundry list" of low-hanging fruit. Note that some of > >> these are being worked on for F8 anyway. > >> > > > > [snip sensible list of low-hanging fruit] > > > > I'd like to add another one: > > > > * get rid of the forced filesystem check every 26th mount. > > > > Rui > > > > > Never heard of "tune2fs"? Just use it to set the mount count higher, > `man tune2fs` Okay, I am going to politely ask for an end to this sort of response in this mailing list. Especially in this thread we are brain-storming on ideas of a desktop fedora spin. Responses of RTFM or google it or whatever are not productive to the purpose of this list. I have heard of tune2fs, and probably every other obscure command sitting on our distribution's filesystem. We are brain storming ideas of what we do and don't want in an experimental spin of Fedora. This might sound harsh, however I want to put an end to it now. This is not Slashdot. If you have a reason that ever 26 reboots on a 300gig file-system a desktop user needs to wait 10 -15 minutes to wait while their journaled filesystem is forced checked then speak up. Otherwise head over to slashdot or digg of wherever and voice your concerns. I am finished now. Jon From mclasen at redhat.com Sun Aug 26 05:28:39 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 26 Aug 2007 01:28:39 -0400 Subject: low-hanging fruit In-Reply-To: <46D108A2.3050608@fedoraproject.org> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> <1187299998.3788.79.camel@oneill.fubar.dk> <46C5D50A.9060109@redhat.com> <46C5D953.1080301@redhat.com> <1187374322.1161.39.camel@localhost.localdomain> <1188104284.4266.9.camel@localhost.localdomain> <46D108A2.3050608@fedoraproject.org> Message-ID: <1188106119.4266.12.camel@localhost.localdomain> On Sun, 2007-08-26 at 10:29 +0530, Rahul Sundaram wrote: > Matthias Clasen wrote: > > > > > - make the panel optionally use file monitoring for desktop files > > backing launchers > > > > Would this automatically remove the panel icons if the apps were > uninstalled? As currently written, no. But the preferred application setting is not changed either if the preferred app is uninstalled. > > > - add some code that maintains preferred-web-browser.desktop and > > preferred-mail-reader.desktop and keeps them in sync with the > > corresponding gconf keys. > > Does it automatically change the icons? Yes From sundaram at fedoraproject.org Sun Aug 26 05:29:44 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 26 Aug 2007 10:59:44 +0530 Subject: low-hanging fruit In-Reply-To: <1188106119.4266.12.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> <1187299998.3788.79.camel@oneill.fubar.dk> <46C5D50A.9060109@redhat.com> <46C5D953.1080301@redhat.com> <1187374322.1161.39.camel@localhost.localdomain> <1188104284.4266.9.camel@localhost.localdomain> <46D108A2.3050608@fedoraproject.org> <1188106119.4266.12.camel@localhost.localdomain> Message-ID: <46D10FC8.2040008@fedoraproject.org> Matthias Clasen wrote: > On Sun, 2007-08-26 at 10:29 +0530, Rahul Sundaram wrote: >> Matthias Clasen wrote: >> >>> - make the panel optionally use file monitoring for desktop files >>> backing launchers >>> >> Would this automatically remove the panel icons if the apps were >> uninstalled? > > As currently written, no. But the preferred application setting is not > changed either if the preferred app is uninstalled. Right but in most instances you would expect the panel icons to go away if the related application is uninstalled. If we can monitor files, we should do that. Rahul From gmureddu at prodigy.net.mx Sun Aug 26 06:10:55 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Sun, 26 Aug 2007 02:10:55 -0400 Subject: low-hanging fruit In-Reply-To: References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> <46D0F563.60904@prodigy.net.mx> Message-ID: <46D1196F.7010507@prodigy.net.mx> Jon Nettleton escribi?: > On 8/25/07, Gian Paolo Mureddu wrote: > >> Rui Tiago Ca??o Matos escribi?: >> >>> On Qua, 2007-08-15 at 15:56 -0400, Matthias Clasen wrote: >>> >>> >>>> As discussed in the meeting, here is my personal >>>> "laundry list" of low-hanging fruit. Note that some of >>>> these are being worked on for F8 anyway. >>>> >>>> >>> [snip sensible list of low-hanging fruit] >>> >>> I'd like to add another one: >>> >>> * get rid of the forced filesystem check every 26th mount. >>> >>> Rui >>> >>> >>> >> Never heard of "tune2fs"? Just use it to set the mount count higher, >> `man tune2fs` >> > > Okay, I am going to politely ask for an end to this sort of response > in this mailing list. Especially in this thread we are brain-storming > on ideas of a desktop fedora spin. Responses of RTFM or google > it or whatever are not productive to the purpose of this list. > > I have heard of tune2fs, and probably every other obscure command > sitting on our distribution's filesystem. We are brain storming ideas > of what we do and don't want in an experimental spin of Fedora. This > might sound harsh, however I want to put an end to it now. This is not > Slashdot. If you have a reason that ever 26 reboots on a 300gig > file-system a desktop user needs to wait 10 -15 minutes to wait > while their journaled filesystem is forced checked then speak up. > Otherwise head over to slashdot or digg of wherever and voice your > concerns. > > I am finished now. > > Jon > > Simple enough take out the 1 (or 2's for additional filesystems) and replace them with 0s in fstab ;) LABEL=/ / ext3 defaults 1 0 -- from 1 to 0 LABEL=/boot /boot ext3 defaults 1 0 -- from 2 to 0 Simple, huh? That second check will take away the "mount count fs check" but may also take away other features... From the man page.... "The sixth field, (fs_passno), is used by the fsck(8) program to deter- mine the order in which filesystem checks are done at reboot time. The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked." Default to 0 seems like what is being discussed, without tampering with tune2fs... I don't like the approach (as that also takes away an extra layer of protection for the hardware and data), but that *will* get rid of the mount count fs checks. Alternatively, force Disk Druid to run tune2fs with the -C 0 option to disable mount-count check on the volume... That change, though I'm not sure would be as simple, though might be the way to go in the long run. From nicolas.mailhot at laposte.net Sun Aug 26 07:57:36 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 26 Aug 2007 09:57:36 +0200 Subject: low-hanging fruit In-Reply-To: <46D0C88E.1000709@fedoraproject.org> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C5488E.7020500@nicubunu.ro> <46D0C88E.1000709@fedoraproject.org> Message-ID: <1188115056.3757.2.camel@rousalka.dyndns.org> > Nicu Buculei wrote: > > Matthias Clasen wrote: > >> As discussed in the meeting, here is my personal "laundry list" of > >> low-hanging fruit. Note that some of > >> these are being worked on for F8 anyway. > > > > I think I can propose another item: take a lesson from ccLiveContent and > > include a little free multimedia content (free as in CC-BY-SA) in the > > default install to show the user the multimedia capabilities. > > This can be 2 or 3 songs in Ogg Vorbis format and 1 or 2 videos in Ogg > > Theora. It does not matter *what* the content it, the videos may be RH > > commercials, interviews with OLPC developers, FUDcon footage, whatever > > as long as is shiny and can be played right away. Anything that includes voices people are supposed to understand needs captioning for an i18n audience -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sundaram at fedoraproject.org Sun Aug 26 10:50:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 26 Aug 2007 16:20:11 +0530 Subject: low-hanging fruit In-Reply-To: <46D1196F.7010507@prodigy.net.mx> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> <46D0F563.60904@prodigy.net.mx> <46D1196F.7010507@prodigy.net.mx> Message-ID: <46D15AE3.20901@fedoraproject.org> Gian Paolo Mureddu wrote: >> > Simple enough take out the 1 (or 2's for additional filesystems) and > replace them with 0s in fstab ;) Again, this is for the desktop users. Do you expect non-technical users to fiddle with fstab? Not a very useful suggestion I think. Rahul From drago01 at gmail.com Sun Aug 26 11:32:11 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 26 Aug 2007 13:32:11 +0200 Subject: Idea: easier transition for newcomers from other DEs/OSes In-Reply-To: <1187975701.9578.203.camel@pc-notebook> References: <1187975701.9578.203.camel@pc-notebook> Message-ID: <46D164BB.7040105@gmail.com> Martin Sourada wrote: > Just a though... Your opinions? Is it even desirable? Does it make > sense? > > -1000 ! --- fedora is not supposed to be a "better windows" but a different OS look & fell can also be different as long as it isn't complicated and the user does not need to RTFM to understand how to do basic task. but to be honest I don'z think that the gnome or kde look and feel are a problem for somebody who switches from windows to linux. The things that are complely different are: * software installation (no setup.exe ..click, click, click) but I think packagekit/pirut and friends are not to complex for windows users to get used to and after sometime they will start to love them (no hunting for apps on the net/disks but simply search for it and the system does the download and install for them) * driver installation: users should not install drivers at all everything should just work everything else its a bug ... the problem here is that some vendors does not help us with this goal. --- I think thats basicly it opening a file using nautilus/konqueror or with the windows explorer isn't much different. starting a app from a menu that is not 1:1 the same as the windows one? well if the user can use the mouse and read he will find the app in menu. I could continue here but I wont what I want to say is USERS AREN'T IDOITS! (well some are but they have problems with other oses to so copying their look & feel does not help) ... making things easier is ok but don't assume that user can't learn anything new. (and in that cases it isn't _that_ new at all) From martin.sourada at seznam.cz Sun Aug 26 11:52:40 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 26 Aug 2007 13:52:40 +0200 Subject: Idea: easier transition for newcomers from other DEs/OSes In-Reply-To: <46D164BB.7040105@gmail.com> References: <1187975701.9578.203.camel@pc-notebook> <46D164BB.7040105@gmail.com> Message-ID: <1188129160.9578.298.camel@pc-notebook> On Sun, 2007-08-26 at 13:32 +0200, dragoran wrote: > Martin Sourada wrote: > > Just a though... Your opinions? Is it even desirable? Does it make > > sense? > > > > > -1000 ! > --- > fedora is not supposed to be a "better windows" but a different OS > look & fell can also be different as long as it isn't complicated and > the user does not need to RTFM to understand how to do basic task. > but to be honest I don'z think that the gnome or kde look and feel are a > problem for somebody who switches from windows to linux. > The things that are complely different are: > * software installation (no setup.exe ..click, click, click) > but I think packagekit/pirut and friends are not to complex for windows > users to get used to and after sometime they will start to love them (no > hunting for apps on the net/disks but simply search for it and the > system does the download and install for them) Actually I think that pirut is far better and easier than just some setup.exe. Besides, you can download a rpm and double-click on it in nautilus, if you don't like pirut itself. Nevertheless, I think it's much more easier to just open applications list, check some apps you want to install/remove and apply the changes. What can be easier? In windows you are nearly unable to (un)install more than one app in one go. The only problems here are that linux apps are not so good known as their windows variants - that's one of the reasons why the group view is cool thing - some of the applications isn't in our repos - but thanks to community the number is lesser and lesser every now and then. > * driver installation: > users should not install drivers at all everything should just work > everything else its a bug ... the problem here is that some vendors does > not help us with this goal. > --- > I think thats basicly it opening a file using nautilus/konqueror or with > the windows explorer isn't much different. starting a app from a menu > that is not 1:1 the same as the windows one? well if the user can use > the mouse and read he will find the app in menu. > I could continue here but I wont what I want to say is USERS AREN'T > IDOITS! (well some are but they have problems with other oses to so > copying their look & feel does not help) ... making things easier is ok > but don't assume that user can't learn anything new. (and in that cases > it isn't _that_ new at all) > +1! I just thought about setting some basic things, like panel layout, keyboard shortcuts and like - no app changes - with one ore two clicks... -------------- 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 drago01 at gmail.com Sun Aug 26 12:03:18 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 26 Aug 2007 14:03:18 +0200 Subject: Idea: easier transition for newcomers from other DEs/OSes In-Reply-To: <1188129160.9578.298.camel@pc-notebook> References: <1187975701.9578.203.camel@pc-notebook> <46D164BB.7040105@gmail.com> <1188129160.9578.298.camel@pc-notebook> Message-ID: <46D16C06.3060002@gmail.com> Martin Sourada wrote: > > Actually I think that pirut is far better and easier than just some > setup.exe. Besides, you can download a rpm and double-click on it in > nautilus, if you don't like pirut itself. Nevertheless, I think it's > much more easier to just open applications list, check some apps you > want to install/remove and apply the changes. What can be easier? In > windows you are nearly unable to (un)install more than one app in one > go. The only problems here are that linux apps are not so good known as > their windows variants - that's one of the reasons why the group view is > cool thing - some of the applications isn't in our repos - but thanks to > community the number is lesser and lesser every now and then. > > > +1 > I just thought about setting some basic things, like panel layout, > keyboard shortcuts and like - no app changes - with one ore two > clicks... > well I installed fedora on some peoples boxes that where (and are still) using windows and nobody complained about things like the panel layout. what keyboard shortcuts? the only thing thats different in the default config is that the super(windows) key does not open the menu. but everything else is the same as in windows: ctrl+c/x/v alt+f4 alt+tab etc. From martin.sourada at seznam.cz Sun Aug 26 12:12:06 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 26 Aug 2007 14:12:06 +0200 Subject: Idea: easier transition for newcomers from other DEs/OSes In-Reply-To: <46D16C06.3060002@gmail.com> References: <1187975701.9578.203.camel@pc-notebook> <46D164BB.7040105@gmail.com> <1188129160.9578.298.camel@pc-notebook> <46D16C06.3060002@gmail.com> Message-ID: <1188130326.9578.304.camel@pc-notebook> On Sun, 2007-08-26 at 14:03 +0200, dragoran wrote: > Martin Sourada wrote: > > > > Actually I think that pirut is far better and easier than just some > > setup.exe. Besides, you can download a rpm and double-click on it in > > nautilus, if you don't like pirut itself. Nevertheless, I think it's > > much more easier to just open applications list, check some apps you > > want to install/remove and apply the changes. What can be easier? In > > windows you are nearly unable to (un)install more than one app in one > > go. The only problems here are that linux apps are not so good known as > > their windows variants - that's one of the reasons why the group view is > > cool thing - some of the applications isn't in our repos - but thanks to > > community the number is lesser and lesser every now and then. > > > > > > > +1 > > I just thought about setting some basic things, like panel layout, > > keyboard shortcuts and like - no app changes - with one ore two > > clicks... > > > well I installed fedora on some peoples boxes that where (and are still) > using windows and nobody complained about things like the panel layout. > what keyboard shortcuts? the only thing thats different in the default > config is that the super(windows) key does not open the menu. > but everything else is the same as in windows: > ctrl+c/x/v > alt+f4 > alt+tab > etc. > Some does and some does not. I always hear KDE people whining about two panel layout in GNOME, while I cannot imagine having only one panel. I think it is much the same with Windows and Mac people, though not to such extent. If the shortcuts were same, KDE would not have a utility for setting them according to user wishes. But yeah, most of them are same (like the copy/paste you mentioned, but I like the select and paste with middle mouse button more), but not ALL. That's the point here. E.g. in gnome when you hit ctrl-alt-del, system monitor does not pop up ;-) -------------- 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 jkeating at redhat.com Sun Aug 26 12:43:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 26 Aug 2007 08:43:29 -0400 Subject: low-hanging fruit In-Reply-To: <46D15AE3.20901@fedoraproject.org> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> <46D0F563.60904@prodigy.net.mx> <46D1196F.7010507@prodigy.net.mx> <46D15AE3.20901@fedoraproject.org> Message-ID: <20070826084329.6722fb26@ender> On Sun, 26 Aug 2007 16:20:11 +0530 Rahul Sundaram wrote: > > Simple enough take out the 1 (or 2's for additional filesystems) > > and replace them with 0s in fstab ;) > > Again, this is for the desktop users. Do you expect non-technical > users to fiddle with fstab? Not a very useful suggestion I think. Unless he's suggesting methods for the spin to make these changes, not the user. -- 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 jrb at redhat.com Sun Aug 26 18:16:33 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Sun, 26 Aug 2007 14:16:33 -0400 Subject: low-hanging fruit In-Reply-To: <20070826084329.6722fb26@ender> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> <46D0F563.60904@prodigy.net.mx> <46D1196F.7010507@prodigy.net.mx> <46D15AE3.20901@fedoraproject.org> <20070826084329.6722fb26@ender> Message-ID: <1188152193.2725.13.camel@localhost.localdomain> On Sun, 2007-08-26 at 08:43 -0400, Jesse Keating wrote: > On Sun, 26 Aug 2007 16:20:11 +0530 > Rahul Sundaram wrote: > > > > Simple enough take out the 1 (or 2's for additional filesystems) > > > and replace them with 0s in fstab ;) > > > > Again, this is for the desktop users. Do you expect non-technical > > users to fiddle with fstab? Not a very useful suggestion I think. > > > Unless he's suggesting methods for the spin to make these changes, not > the user. Lets charitably assume he is... Can we make this change within a spin though, without forking a package? Thanks, -Jonathan From gmureddu at prodigy.net.mx Sun Aug 26 21:44:00 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Sun, 26 Aug 2007 17:44:00 -0400 Subject: low-hanging fruit In-Reply-To: <20070826084329.6722fb26@ender> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> <46D0F563.60904@prodigy.net.mx> <46D1196F.7010507@prodigy.net.mx> <46D15AE3.20901@fedoraproject.org> <20070826084329.6722fb26@ender> Message-ID: <46D1F420.8070601@prodigy.net.mx> Jesse Keating escribi?: > On Sun, 26 Aug 2007 16:20:11 +0530 > Rahul Sundaram wrote: > > >>> Simple enough take out the 1 (or 2's for additional filesystems) >>> and replace them with 0s in fstab ;) >>> >> Again, this is for the desktop users. Do you expect non-technical >> users to fiddle with fstab? Not a very useful suggestion I think. >> > > > Unless he's suggesting methods for the spin to make these changes, not > the user. > > Indeed I was. I was making these suggestions for the spin, not for regular users. From gmureddu at prodigy.net.mx Sun Aug 26 22:01:20 2007 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Sun, 26 Aug 2007 18:01:20 -0400 Subject: low-hanging fruit In-Reply-To: <46D1F420.8070601@prodigy.net.mx> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> <46D0F563.60904@prodigy.net.mx> <46D1196F.7010507@prodigy.net.mx> <46D15AE3.20901@fedoraproject.org> <20070826084329.6722fb26@ender> <46D1F420.8070601@prodigy.net.mx> Message-ID: <46D1F830.1070201@prodigy.net.mx> Gian Paolo Mureddu escribi?: > Indeed I was. I was making these suggestions for the spin, not for > regular users. > Sorry for the double post and reply to myself.. Detailed explanation: Make a change in the way the "Desktop" spin is handled and possibly take some of the "special tuning" to get these things going and possibly make them into: a) A complementary initscript which would be stand-alone and which would then, either: *Zero the mount count on ext2/3/4 filesystems upon first boot, leaving evidence in /etc/ that the change has been made, so on each reboot the presence of this file is checked and boot as usual (I find this to be somewhat convoluted, but some might think it is a good idea, and since we're brainstorming I post it), or *alternatively the idea would be the same, but instead of zeroing the mount count (with the use of tune2fs, parsing the information from fstab), have the script change fstab itself.... Or b) Have the script as part of the Anaconda routine for the installation process and run this "post-install" script and perform either of the above mentioned "workarounds". I still believe that the way to go would be to have a subroutine in Disk Druid, make a *selectable* option so that users can have an option whether they want their drives checked every 'x' number of mounts or not, and the amount; made available only for the custom partition layout (most likely seen only by "power users") and default to running `tune2fs -C 0` in default behavior, after partition formatting, and showing only a message like "Preparing the hard disk partitions for installation" or some such, also dump the corresponding actions to the "log" console, and possibly prior the actions take effect show a summary window (just like the "The following partitions have been selected to be formatted" window, in fact in the same window) showing the mount times each partition will be allowed to be mounted prior being forced checked or some such... Again this is aimed primarily for experienced users and most likely will be only used in special applications, like servers or production workstations and such. Once more, I'm thinking of this as a long-term solution for mainline Fedora and not necessarily for a "Desktop" spin, but we could at least give it a try in the Desktop spin, especially with the sixth fstab field. From krh at bitplanet.net Mon Aug 27 01:25:56 2007 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Sun, 26 Aug 2007 21:25:56 -0400 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> Message-ID: <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> On 8/24/07, Jon Nettleton wrote: > On 8/24/07, Christopher Aillon wrote: > > Arthur Pemberton wrote: > > > Is there a problem with RHGB? I haven't heard of one in the chatrooms > > > or mailing list. > > > > The main problem is that it starts an X server. When rhgb ends, its X > > server shuts down, and then a second X server is spawned for the user to > > log in with. > > I am working on this. Hopefully we will have only 1 Xserver running from boot > to desktop. Hi, Allow me to give a summary of the graphical boot plans we've been discussion at Red Hat and what the bigger picture looks like for the graphical stack. We have a wiki-page over here: http://fedoraproject.org/wiki/Releases/FeatureBetterStartup that describes the plan, but let me just quickly summarize what we hope to get done for F9 (optimistic, but realistic): - We switch to graphics mode using the DRM drivers, which we add to the initrd. This mean we can display a logo as soon as the kernel finishes initializing and starts the initrd, which is about 5-10 seconds after grub. Ray has been working on a small application we can put in the initrd that displays boot progress. This won't require X, most likely just libpng, possibly cairo and will run all the way to GDM. When GDM start, we start the X server, which won't change the mode, but inherit the mode and screen contents set by the drm drivers and the graphical boot application. Now, getting all this in place takes a few steps: 1) Get DRM memory manager in to kernel. This is our top priority right now. It blocks on the work Dave Airlie is doing with exa integration, sorting out caching and the super-submit-ioctl. It blocks on verifying that the memory manager is usable for redirected direct rendering and GLX 1.4 (GLXPixmaps and GLXPbuffers), which I have been working on. We expect to get these issues worked out at XDS in a couple of weeks, and if all goes well we may get the memory manager into 2.6.24. 2) Move DDX modesetting code into the drm drivers. So far, the idea has been pretty well received upstream (kernel) and to some extent, it's just a matter of moving the code, but there is also the issue of working out the userspace interface. This work is already happening, Jesse Barnes and others have been prototyping this and they have a wiki page here discussion the changes they're planning: http://dri.freedesktop.org/wiki/DrmModesetting 3) Make the boot sequence use the DRM drives; includes work in mkinitrd, RHGB, GDM, X, and likely other packages, and of course the new graphical boot application it self (Ray has most of the boot application done). This is mostly a Fedora integration effort uses and integrates the new functionality with our boot sequence. In the meantime ( = Fedora 8 and worst case 9), we're not really looking to: - Use fbdev/bootsplash/splashy. It's actually a long standing discussion within Red Hat. It has been suggested many times and dismissed many times. DRM can coexist with fbdev, but it's not pretty and some people are concerned about the stability of X running alongside an fbdev driver. Also, we don't want to rely on and maintain another modesetting code path. DRM modesetting will use the same code base as X drivers and when we have DRM modesetting, X will use those that for setting modes. - Rock the boat with respect to the X startup sequence. We've had RHGB for a long time, and shaking up the way RHGB, GDM and X start up and interact just before we land the new DRM modesetting make little sense. It's a delicate and fragile part of the boot process and there's a lot of tricky issues to get right. The small benefit we get from moving these around doesn't match up with the risks, especially not for Fedora 8 which freezes in two days. Kristian From jon.nettleton at gmail.com Mon Aug 27 03:46:03 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Sun, 26 Aug 2007 23:46:03 -0400 Subject: More low hanging fruit. In-Reply-To: <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> Message-ID: On 8/26/07, Kristian H?gsberg wrote: > On 8/24/07, Jon Nettleton wrote: > > On 8/24/07, Christopher Aillon wrote: > > > Arthur Pemberton wrote: > > > > Is there a problem with RHGB? I haven't heard of one in the chatrooms > > > > or mailing list. > > > > > > The main problem is that it starts an X server. When rhgb ends, its X > > > server shuts down, and then a second X server is spawned for the user to > > > log in with. > > > > I am working on this. Hopefully we will have only 1 Xserver running from boot > > to desktop. > > Hi, > > Allow me to give a summary of the graphical boot plans we've been > discussion at Red Hat and what the bigger picture looks like for the > graphical stack. We have a wiki-page over here: > > http://fedoraproject.org/wiki/Releases/FeatureBetterStartup > > that describes the plan, but let me just quickly summarize what we > hope to get done for F9 (optimistic, but realistic): > > - We switch to graphics mode using the DRM drivers, which we add to > the initrd. This mean we can display a logo as soon as the kernel > finishes initializing and starts the initrd, which is about 5-10 > seconds after grub. Ray has been working on a small application we > can put in the initrd that displays boot progress. This won't require > X, most likely just libpng, possibly cairo and will run all the way to > GDM. When GDM start, we start the X server, which won't change the > mode, but inherit the mode and screen contents set by the drm drivers > and the graphical boot application. > > Now, getting all this in place takes a few steps: > > 1) Get DRM memory manager in to kernel. This is our top priority > right now. It blocks on the work Dave Airlie is doing with exa > integration, sorting out caching and the super-submit-ioctl. It > blocks on verifying that the memory manager is usable for redirected > direct rendering and GLX 1.4 (GLXPixmaps and GLXPbuffers), which I > have been working on. We expect to get these issues worked out at XDS > in a couple of weeks, and if all goes well we may get the memory > manager into 2.6.24. > > 2) Move DDX modesetting code into the drm drivers. So far, the idea > has been pretty well received upstream (kernel) and to some extent, > it's just a matter of moving the code, but there is also the issue of > working out the userspace interface. This work is already happening, > Jesse Barnes and others have been prototyping this and they have a > wiki page here discussion the changes they're planning: > > http://dri.freedesktop.org/wiki/DrmModesetting > > 3) Make the boot sequence use the DRM drives; includes work in > mkinitrd, RHGB, GDM, X, and likely other packages, and of course the > new graphical boot application it self (Ray has most of the boot > application done). This is mostly a Fedora integration effort uses > and integrates the new functionality with our boot sequence. > > In the meantime ( = Fedora 8 and worst case 9), we're not really looking to: > > - Use fbdev/bootsplash/splashy. It's actually a long standing > discussion within Red Hat. It has been suggested many times and > dismissed many times. DRM can coexist with fbdev, but it's not > pretty and some people are concerned about the stability of X running > alongside an fbdev driver. Also, we don't want to rely on and > maintain another modesetting code path. DRM modesetting will use the > same code base as X drivers and when we have DRM modesetting, X will > use those that for setting modes. > > - Rock the boat with respect to the X startup sequence. We've had > RHGB for a long time, and shaking up the way RHGB, GDM and X start up > and interact just before we land the new DRM modesetting make little > sense. It's a delicate and fragile part of the boot process and > there's a lot of tricky issues to get right. The small benefit we get > from moving these around doesn't match up with the risks, especially > not for Fedora 8 which freezes in two days. > I am sorry but this is really the perfect example of Fedora's problem. The community tries to better the project and is slapped down at the last minute because in some hidden meeting the powers that be have decided a different roadmap. I love NetworkManager but I have been waiting 2+ years for functionality that I wrote into the existing network init stuff (wireless ap scanning and profiles). I guess when Fedora X is released we will get all the great functionality mentioned above. I am greatly saddened and discouraged by this sort of response to an exciting and interesting thread. Maybe the future really is a CentOS like fork for the desktop, and not just a spin. Jon From pemboa at gmail.com Mon Aug 27 04:25:54 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 26 Aug 2007 23:25:54 -0500 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> Message-ID: <16de708d0708262125o1ecb0dcxf9d1f497bb1e1da4@mail.gmail.com> On 8/26/07, Jon Nettleton wrote: > I am sorry but this is really the perfect example of Fedora's problem. > The community tries to better the project and is slapped down at the > last minute because in some hidden meeting the powers that be > have decided a different roadmap. This seems to have been developed and publicized on the Fedora wiki page since 2007-05-08. I'm not sure how that is last minute or hidden. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jon.nettleton at gmail.com Mon Aug 27 04:58:35 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Mon, 27 Aug 2007 00:58:35 -0400 Subject: More low hanging fruit. In-Reply-To: <16de708d0708262125o1ecb0dcxf9d1f497bb1e1da4@mail.gmail.com> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> <16de708d0708262125o1ecb0dcxf9d1f497bb1e1da4@mail.gmail.com> Message-ID: On 8/27/07, Arthur Pemberton wrote: > On 8/26/07, Jon Nettleton wrote: > > > I am sorry but this is really the perfect example of Fedora's problem. > > The community tries to better the project and is slapped down at the > > last minute because in some hidden meeting the powers that be > > have decided a different roadmap. > > > This seems to have been developed and publicized on the Fedora wiki > page since 2007-05-08. I'm not sure how that is last minute or hidden. > So we are going to hold back our desktop user community a better boot process for 10 better seconds of kernel rendered graphics? What is the next thing we have to wait for? As far as I know all our first boot and admin utilities are written to use X or ncurses. Booting to an X server as fast as possible allows us to embed X admin utilites already written. Otherwise we are stuck using ncurses and text to set the time server and change the root password. Or are we going to rewrite these utilties also? I understand that people feel the future is in DDX but is that replacing X on the desktop? If it isn't then shouldn't the future of a DESKTOP version of fedora be to get to X ASAP and stay in X? If the question is no then I will gladly unsubscribe from this list and not be part of the problem any longer. Jon From pemboa at gmail.com Mon Aug 27 05:04:15 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 27 Aug 2007 00:04:15 -0500 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> <16de708d0708262125o1ecb0dcxf9d1f497bb1e1da4@mail.gmail.com> Message-ID: <16de708d0708262204u4bce3f2gf6c48d19951b4cd8@mail.gmail.com> On 8/26/07, Jon Nettleton wrote: > On 8/27/07, Arthur Pemberton wrote: > > On 8/26/07, Jon Nettleton wrote: > > > > > I am sorry but this is really the perfect example of Fedora's problem. > > > The community tries to better the project and is slapped down at the > > > last minute because in some hidden meeting the powers that be > > > have decided a different roadmap. > > > > > > This seems to have been developed and publicized on the Fedora wiki > > page since 2007-05-08. I'm not sure how that is last minute or hidden. > > > > So we are going to hold back our desktop user community a better boot > process for 10 better seconds of kernel rendered graphics? What is the > next thing we have to wait for? As far as I know all our first boot and admin > utilities are written to use X or ncurses. Booting to an X server as fast as > possible allows us to embed X admin utilites already written. > Otherwise we are stuck using ncurses and text to set the time > server and change the root password. Or are we going to rewrite these > utilties also? I understand that people feel the future is in DDX but is that > replacing X on the desktop? If it isn't then shouldn't the future of a DESKTOP > version of fedora be to get to X ASAP and stay in X? > > If the question is no then I will gladly unsubscribe from this list and not > be part of the problem any longer. You need to calm down. I only quoted and replied to a small portion your post. I am not the person to answer all these questions, so there's no point to replying to my message with these question. You mentioned 'hidden' and 'last minute' and I only disagreed with that. I am not prepared to argue against/for the merits of an early Xorg etc. I only originally asked a question since you seemed to be aware of a problem with RHGB that I was not aware of, and wanted to be informed. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From katzj at redhat.com Mon Aug 27 13:55:17 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Aug 2007 09:55:17 -0400 Subject: low-hanging fruit In-Reply-To: <1188084235.3052.2.camel@hive> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> Message-ID: <1188222917.2365.5.camel@localhost.localdomain> On Sun, 2007-08-26 at 00:23 +0100, Rui Tiago Ca??o Matos wrote: > On Qua, 2007-08-15 at 15:56 -0400, Matthias Clasen wrote: > > As discussed in the meeting, here is my personal > > "laundry list" of low-hanging fruit. Note that some of > > these are being worked on for F8 anyway. > > [snip sensible list of low-hanging fruit] > > I'd like to add another one: > > * get rid of the forced filesystem check every 26th mount. How was your filesystem created? anaconda has been doing this on ext3 filesystems since we first started doing ext3 many years ago[1]. Jeremy [1] From a brief trip down cvs memory lane, it looks like that was 2001/08/14. From walters at redhat.com Mon Aug 27 14:19:09 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 27 Aug 2007 10:19:09 -0400 Subject: low-hanging fruit In-Reply-To: <1188222917.2365.5.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> <1188222917.2365.5.camel@localhost.localdomain> Message-ID: On 8/27/07, Jeremy Katz wrote: > > On Sun, 2007-08-26 at 00:23 +0100, Rui Tiago Ca??o Matos wrote: > > On Qua, 2007-08-15 at 15:56 -0400, Matthias Clasen wrote: > > > As discussed in the meeting, here is my personal > > > "laundry list" of low-hanging fruit. Note that some of > > > these are being worked on for F8 anyway. > > > > [snip sensible list of low-hanging fruit] > > > > I'd like to add another one: > > > > * get rid of the forced filesystem check every 26th mount. > > How was your filesystem created? anaconda has been doing this on ext3 > filesystems since we first started doing ext3 many years ago[1]. Yeah I was going to say, I don't think I've seen the ext3 forced check in years. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mzerqung at 0pointer.de Mon Aug 27 14:19:48 2007 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 27 Aug 2007 16:19:48 +0200 Subject: PA by default In-Reply-To: <1187644706.3208.51.camel@cookie.hadess.net> References: <1187301234.26239.30.camel@cookie.hadess.net> <20070820201051.GH25276@tango.0pointer.de> <1187642245.3208.32.camel@cookie.hadess.net> <20070820210150.GB28560@tango.0pointer.de> <1187644706.3208.51.camel@cookie.hadess.net> Message-ID: <20070827141948.GA5488@tango.0pointer.de> On Mon, 20.08.07 22:18, Bastien Nocera (bnocera at redhat.com) wrote: > We're mixing 2 different things. There's the per-stream volume, for the > GstPulseSink for use in gnome-volume-control, and there's detecting that > we have a "stream" volume, for Totem and Rhythmbox. > > The former I don't think is very important right now, as long as the > latter is implemented. > > A simple read-only property would be enough to handle that. Hmm, what would this property export? I am not sure I understand what you are suggesting. > Does MacOS X present a similar interface for applications to use, or > do they implement volume control by themselves like Totem/Rhythmbox > currently do with the volume element? The only a have a single per-stream volume which is controlled by the slider in iTunes. The per-system volume is controlled globally with the volume hotkeys. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From walters at redhat.com Mon Aug 27 14:37:22 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 27 Aug 2007 10:37:22 -0400 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> Message-ID: On 8/26/07, Jon Nettleton wrote: > > > I am sorry but this is really the perfect example of Fedora's problem. > The community tries to better the project and is slapped down at the > last minute because in some hidden meeting the powers that be > have decided a different roadmap. Have you posted your patches? Maybe they turn out to be simple enough? I guess when Fedora X is released we will get all the great functionality > mentioned above. I am greatly saddened and discouraged by this > sort of response to an exciting and interesting thread. Maybe the > future really is a CentOS like fork for the desktop, and not just a spin. What the Desktop SIG/spin is about is to do the small tweaks to Fedora to make it a better desktop. If we get blocked on some larger changes to the underlying OS (like this bootup sequence), the answer isn't to fork. Let's be honest, there are a bazillion other Linux distributions out there, I think few people here have the desire to add to the pool. Keep in mind what makes Fedora Fedora (among other things, but in this context...) is that we try to get everything upstream and we try to have a unified code base. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiagomatos at gmail.com Mon Aug 27 15:46:53 2007 From: tiagomatos at gmail.com (Rui Tiago =?ISO-8859-1?Q?Ca=E7=E3o?= Matos) Date: Mon, 27 Aug 2007 16:46:53 +0100 Subject: low-hanging fruit In-Reply-To: <1188222917.2365.5.camel@localhost.localdomain> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> <1188222917.2365.5.camel@localhost.localdomain> Message-ID: <1188229613.3054.6.camel@hive> On Seg, 2007-08-27 at 09:55 -0400, Jeremy Katz wrote: > How was your filesystem created? anaconda has been doing this on ext3 > filesystems since we first started doing ext3 many years ago[1]. Ups, sorry for the noise then. This filesystem wasn't created by anaconda. I manually issued "tune2fs -c 0" on it now. Rui -------------- 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 nicolas.mailhot at laposte.net Mon Aug 27 16:35:41 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 27 Aug 2007 18:35:41 +0200 Subject: low-hanging fruit In-Reply-To: <1188229613.3054.6.camel@hive> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> <1188222917.2365.5.camel@localhost.localdomain> <1188229613.3054.6.camel@hive> Message-ID: <1188232541.3135.0.camel@rousalka.dyndns.org> Le lundi 27 ao?t 2007 ? 16:46 +0100, Rui Tiago Ca??o Matos a ?crit : > On Seg, 2007-08-27 at 09:55 -0400, Jeremy Katz wrote: > > How was your filesystem created? anaconda has been doing this on ext3 > > filesystems since we first started doing ext3 many years ago[1]. > > Ups, sorry for the noise then. This filesystem wasn't created by > anaconda. I manually issued "tune2fs -c 0" on it now. Though one could argue the lowlevel ext2/ext3 tools should have another default when creating a filesystem with a journal -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From krh at bitplanet.net Mon Aug 27 17:19:51 2007 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 27 Aug 2007 13:19:51 -0400 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> <16de708d0708262125o1ecb0dcxf9d1f497bb1e1da4@mail.gmail.com> Message-ID: <59ad55d30708271019i37f2f9a1ke330d4f4c173722f@mail.gmail.com> On 8/27/07, Jon Nettleton wrote: > On 8/27/07, Arthur Pemberton wrote: > > On 8/26/07, Jon Nettleton wrote: > > > > > I am sorry but this is really the perfect example of Fedora's problem. > > > The community tries to better the project and is slapped down at the > > > last minute because in some hidden meeting the powers that be > > > have decided a different roadmap. > > > > > > This seems to have been developed and publicized on the Fedora wiki > > page since 2007-05-08. I'm not sure how that is last minute or hidden. > > > > So we are going to hold back our desktop user community a better boot > process for 10 better seconds of kernel rendered graphics? What is the > next thing we have to wait for? It's not kernel rendered graphics, the kernel just sets the graphics mode and then a small userspace application can provide a simple progress bar. The userspace application will start very early in the boot process and replace RHGB, so we still avoid starting 2 X servers with this approach. The transition from the userspace application to the X server will be smooth, for example, a cross fade, and in particular, no mode switches. > As far as I know all our first boot and admin > utilities are written to use X or ncurses. Booting to an X server as fast as > possible allows us to embed X admin utilites already written. > Otherwise we are stuck using ncurses and text to set the time > server and change the root password. Or are we going to rewrite these > utilties also? No, that was not part of what I wrote. All those tools are still going to require an X server, and we're not going to move away from X. > I understand that people feel the future is in DDX but is that > replacing X on the desktop? DDX is the part of X that drives the hardware, Driver Dependent X. When X hackers talk about DDX drivers, they're really just talking about the 2D driver part of the X server. The DRM modesetting effort is about moving the modesetting part of the DDX driver into the kernel, so that the kernel can set the mode on boot or in the initrd (the earliest userspace). This has a number of other benefits, for example, the kernel can then restore a garbled display if your X server crashes, or if the kernel crashes it can print an oops on screen even if you're in X. > If it isn't then shouldn't the future of a DESKTOP > version of fedora be to get to X ASAP and stay in X? > If the question is no then I will gladly unsubscribe from this list and not > be part of the problem any longer. The most important part is to boot into a desktop session as fast as possible. Where in the boot sequence we start X is less important, but as soon as we can set the graphics mode a provide graphical feedback the better. The earliest time where we can do this is the initrd. Kristian From stevelist at silverorange.com Mon Aug 27 17:25:57 2007 From: stevelist at silverorange.com (Steven Garrity) Date: Mon, 27 Aug 2007 14:25:57 -0300 Subject: More low hanging fruit. In-Reply-To: <59ad55d30708271019i37f2f9a1ke330d4f4c173722f@mail.gmail.com> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> <16de708d0708262125o1ecb0dcxf9d1f497bb1e1da4@mail.gmail.com> <59ad55d30708271019i37f2f9a1ke330d4f4c173722f@mail.gmail.com> Message-ID: <46D30925.7080801@silverorange.com> Kristian H?gsberg wrote: > It's not kernel rendered graphics, the kernel just sets the graphics > mode and then a small userspace application can provide a simple > progress bar. The userspace application will start very early in the > boot process and replace RHGB, so we still avoid starting 2 X servers > with this approach. The transition from the userspace application to > the X server will be smooth, for example, a cross fade, and in > particular, no mode switches. Isn't the small userspace app you're describing here very similar to Splashy [1]? Cheers, Steven Garrity (who admittedly knows very little about this topic) [1] http://splashy.alioth.debian.org/ From krh at bitplanet.net Mon Aug 27 17:39:28 2007 From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=) Date: Mon, 27 Aug 2007 13:39:28 -0400 Subject: More low hanging fruit. In-Reply-To: <46D30925.7080801@silverorange.com> References: <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> <16de708d0708262125o1ecb0dcxf9d1f497bb1e1da4@mail.gmail.com> <59ad55d30708271019i37f2f9a1ke330d4f4c173722f@mail.gmail.com> <46D30925.7080801@silverorange.com> Message-ID: <59ad55d30708271039v36c84265kcc2c0098865dfc4f@mail.gmail.com> On 8/27/07, Steven Garrity wrote: > Kristian H?gsberg wrote: > > It's not kernel rendered graphics, the kernel just sets the graphics > > mode and then a small userspace application can provide a simple > > progress bar. The userspace application will start very early in the > > boot process and replace RHGB, so we still avoid starting 2 X servers > > with this approach. The transition from the userspace application to > > the X server will be smooth, for example, a cross fade, and in > > particular, no mode switches. > > Isn't the small userspace app you're describing here very similar to > Splashy [1]? It may well make more sense to go with that, but we need to take a closer look. A few things that we need that I don't think splashy does: - we're going to use the drm fbdev or maybe drm ioctls to set and control the graphics as opposed the the current fbdev system. The drm drivers and the current fbdev arbitrate access to the underlying in graphics device in a pretty hacky way that we want to avoid. - we want to make sure that the drm driver sets the right mode right from the start so that we can do a nice transition effect into the X server without changing mode. This requires some hand-off protocol between splasy and the X server so the X server wont clear the framebuffer contents on startup. That said, I can't see why these features wouldn't be accepted by the splashy project, once the drm modesetting is in place. Kristian From dmc.fedora at filteredperception.org Mon Aug 27 19:48:31 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 27 Aug 2007 14:48:31 -0500 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> Message-ID: <46D32A8F.9010701@filteredperception.org> Colin Walters wrote: > On 8/26/07, Jon Nettleton wrote: >> >> I am sorry but this is really the perfect example of Fedora's problem. >> The community tries to better the project and is slapped down at the >> last minute because in some hidden meeting the powers that be >> have decided a different roadmap. > > > Have you posted your patches? Maybe they turn out to be simple enough? +1 And just because they might not make it into the default boot sequence, doesn't mean there might not be plenty of people who would like a simple installable package which made those changes to their systems. -dmc From lemsx1 at gmail.com Mon Aug 27 20:05:40 2007 From: lemsx1 at gmail.com (Luis Mondesi) Date: Mon, 27 Aug 2007 16:05:40 -0400 Subject: More low hanging fruit. In-Reply-To: <46D32A8F.9010701@filteredperception.org> References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> <46D32A8F.9010701@filteredperception.org> Message-ID: Hello all, I'm the main developer (and project admin) of the Splashy project. Somebody mentioned this threat on the #splashy channel (irc.freenode.net) and I decided to join the list and follow it closely. We are very interested in getting Splashy on Fedora. We have worked with a few Fedora developers before in order to get a .spec file that's generic enough for most RPM-based systems. Now that Splashy depends on less debian-specific libraries, I think it's time to start supporting Fedora in full. As you might already know, Xandros, SuSE and Mandriva are already considering or using Splashy on their projects. And so are other vendors (small integrators and other people who customize Linux distributions). I believe that this will be easier for all of them if there was a src.rpmofficially released from the Splashy project page. If anybody is interested in helping us, please join us on IRC to discuss about it. Regards, -- ----)(----- Luis Mondesi Maestro Debiano ----- START ENCRYPTED BLOCK (Triple-ROT13) ------ Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur fbsgjner jbeyq. ----- END ENCRYPTED BLOCK (Triple-ROT13) ------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From stevelist at silverorange.com Mon Aug 27 20:17:08 2007 From: stevelist at silverorange.com (Steven Garrity) Date: Mon, 27 Aug 2007 17:17:08 -0300 Subject: More low hanging fruit. In-Reply-To: References: <1187969744.3054.6.camel@halflap.boston.devel.redhat.com> <46CF19E2.4090907@prodigy.net.mx> <16de708d0708241515s4c82eaddic2d283d7e5b54727@mail.gmail.com> <46CF7099.4010104@redhat.com> <59ad55d30708261825p38f17d75l19fd8cad40eacfeb@mail.gmail.com> <46D32A8F.9010701@filteredperception.org> Message-ID: <46D33144.3010401@silverorange.com> Luis Mondesi wrote: > We are very interested in getting Splashy on Fedora. We have worked with > a few Fedora developers before in order to get a .spec file that's > generic enough for most RPM-based systems. Now that Splashy depends on > less debian-specific libraries, I think it's time to start supporting > Fedora in full. > > As you might already know, Xandros, SuSE and Mandriva are already > considering or using Splashy on their projects. And so are other vendors > (small integrators and other people who customize Linux distributions). > I believe that this will be easier for all of them if there was a > src.rpm officially released from the Splashy project page. It might be a good start to get Splashy into the Fedora repo so we can easily "yum install" it to try it out. Cheers, Steven Garrity From notting at redhat.com Mon Aug 27 20:54:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Aug 2007 16:54:43 -0400 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <1187035831.6196.15.camel@oneill.fubar.dk> References: <1185920349.12650.4.camel@neutron.verbum.private> <1187021402.2998.12.camel@oneill.fubar.dk> <1187033932.2729.114.camel@localhost.localdomain> <1187034966.4921.28.camel@localhost.localdomain> <1187035831.6196.15.camel@oneill.fubar.dk> Message-ID: <20070827205443.GA23719@nostromo.devel.redhat.com> David Zeuthen (davidz at redhat.com) said: > > On Mon, 2007-08-13 at 15:56 -0400, Jeremy Katz wrote: > > On Mon, 2007-08-13 at 15:38 -0400, Jonathan Blandford wrote: > > > On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote: > > > > One thing we probably want on the desktop live cd, compared to mainline > > > > Fedora, is making sure that the user's home directory are > > > > world-executable, e.g. like this > > > > > > It's less of a low-hanging fruit, but I would love to also see us give > > > every new account a random icon by default. It would be much cooler to > > > see that than the question-mark silhouette. > > > > random requires useradd hacking... something other than the question > > mark just requires dropping something in /etc/skel... > > Ideally we'd just ask questions like these (plus preselecting a suitable > random one) as part of the installation process including using GNOME > Cheese / ktuberling / etc. style apps available. Other things I'd like > to see is the ability to select the desktop background / color scheme / > whatever. It's also a nice place to plug in migration tools to fetch > this data from another OS / whatever. > > Also, it's preferable to do this at install time rather than firstboot > time. Because I'm not so sure firstboot makes a lot of sense for a > desktop/laptop targeted OS (though I'm sure it's great for enterprise > workstation deployments). ? Surely all the 'create user' bits (which are in firstboot) are where you'd do this. Unless you want to move those into anaconda itself. Bill From bnocera at redhat.com Tue Aug 28 10:14:43 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 28 Aug 2007 11:14:43 +0100 Subject: low-hanging fruit In-Reply-To: <46D10FC8.2040008@fedoraproject.org> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> <1187299998.3788.79.camel@oneill.fubar.dk> <46C5D50A.9060109@redhat.com> <46C5D953.1080301@redhat.com> <1187374322.1161.39.camel@localhost.localdomain> <1188104284.4266.9.camel@localhost.localdomain> <46D108A2.3050608@fedoraproject.org> <1188106119.4266.12.camel@localhost.localdomain> <46D10FC8.2040008@fedoraproject.org> Message-ID: <1188296083.9698.43.camel@cookie.hadess.net> On Sun, 2007-08-26 at 10:59 +0530, Rahul Sundaram wrote: > Matthias Clasen wrote: > > On Sun, 2007-08-26 at 10:29 +0530, Rahul Sundaram wrote: > >> Matthias Clasen wrote: > >> > >>> - make the panel optionally use file monitoring for desktop files > >>> backing launchers > >>> > >> Would this automatically remove the panel icons if the apps were > >> uninstalled? > > > > As currently written, no. But the preferred application setting is not > > changed either if the preferred app is uninstalled. > > Right but in most instances you would expect the panel icons to go away > if the related application is uninstalled. If we can monitor files, we > should do that. Actually, right now, you'd get a broken launcher for custom launchers (ie. the ones added from the menu). From bnocera at redhat.com Tue Aug 28 10:16:23 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 28 Aug 2007 11:16:23 +0100 Subject: low-hanging fruit In-Reply-To: <1188115056.3757.2.camel@rousalka.dyndns.org> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C5488E.7020500@nicubunu.ro> <46D0C88E.1000709@fedoraproject.org> <1188115056.3757.2.camel@rousalka.dyndns.org> Message-ID: <1188296183.9698.45.camel@cookie.hadess.net> On Sun, 2007-08-26 at 09:57 +0200, Nicolas Mailhot wrote: > > Nicu Buculei wrote: > > > Matthias Clasen wrote: > > >> As discussed in the meeting, here is my personal "laundry list" of > > >> low-hanging fruit. Note that some of > > >> these are being worked on for F8 anyway. > > > > > > I think I can propose another item: take a lesson from ccLiveContent and > > > include a little free multimedia content (free as in CC-BY-SA) in the > > > default install to show the user the multimedia capabilities. > > > This can be 2 or 3 songs in Ogg Vorbis format and 1 or 2 videos in Ogg > > > Theora. It does not matter *what* the content it, the videos may be RH > > > commercials, interviews with OLPC developers, FUDcon footage, whatever > > > as long as is shiny and can be played right away. > > Anything that includes voices people are supposed to understand needs > captioning for an i18n audience Totem supports text subtitles, which should be pretty easy to translate with a gettext infrastructure. From sundaram at fedoraproject.org Tue Aug 28 13:34:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 28 Aug 2007 19:04:00 +0530 Subject: low-hanging fruit In-Reply-To: <1188296083.9698.43.camel@cookie.hadess.net> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <46C3E979.20409@nicubunu.ro> <1187299998.3788.79.camel@oneill.fubar.dk> <46C5D50A.9060109@redhat.com> <46C5D953.1080301@redhat.com> <1187374322.1161.39.camel@localhost.localdomain> <1188104284.4266.9.camel@localhost.localdomain> <46D108A2.3050608@fedoraproject.org> <1188106119.4266.12.camel@localhost.localdomain> <46D10FC8.2040008@fedoraproject.org> <1188296083.9698.43.camel@cookie.hadess.net> Message-ID: <46D42448.2080703@fedoraproject.org> Bastien Nocera wrote: > On Sun, 2007-08-26 at 10:59 +0530, Rahul Sundaram wrote: >> Matthias Clasen wrote: >>> On Sun, 2007-08-26 at 10:29 +0530, Rahul Sundaram wrote: >>>> Matthias Clasen wrote: >>>> >>>>> - make the panel optionally use file monitoring for desktop files >>>>> backing launchers >>>>> >>>> Would this automatically remove the panel icons if the apps were >>>> uninstalled? >>> As currently written, no. But the preferred application setting is not >>> changed either if the preferred app is uninstalled. >> Right but in most instances you would expect the panel icons to go away >> if the related application is uninstalled. If we can monitor files, we >> should do that. > > Actually, right now, you'd get a broken launcher for custom launchers > (ie. the ones added from the menu). I know that. I consider that a bug. Rahul From jrb at redhat.com Tue Aug 28 15:26:04 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Tue, 28 Aug 2007 11:26:04 -0400 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <20070827205443.GA23719@nostromo.devel.redhat.com> References: <1185920349.12650.4.camel@neutron.verbum.private> <1187021402.2998.12.camel@oneill.fubar.dk> <1187033932.2729.114.camel@localhost.localdomain> <1187034966.4921.28.camel@localhost.localdomain> <1187035831.6196.15.camel@oneill.fubar.dk> <20070827205443.GA23719@nostromo.devel.redhat.com> Message-ID: <1188314764.2737.22.camel@localhost.localdomain> On Mon, 2007-08-27 at 16:54 -0400, Bill Nottingham wrote: > > Also, it's preferable to do this at install time rather than firstboot > > time. Because I'm not so sure firstboot makes a lot of sense for a > > desktop/laptop targeted OS (though I'm sure it's great for enterprise > > workstation deployments). > > ? Surely all the 'create user' bits (which are in firstboot) are where > you'd do this. Unless you want to move those into anaconda itself. I think what David is getting at is that we would like to have only one install experience for the user. Right now, we have two install experiences -- the first when you run anaconda, the second when you hit firstboot. In the managed desktop case (enterprise workstations) the install is split between the admin who does the install on the machine and the enduser does the 'install' by setting up accounts/timezones. David is proposing to merge those for the desktop spin. It's a bit aspirational, and there's a lot that should be cleaned up in firstboot first. But I think it's a good experience, too. Thanks, -Jonathan From notting at redhat.com Tue Aug 28 17:41:11 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 28 Aug 2007 13:41:11 -0400 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <1188314764.2737.22.camel@localhost.localdomain> References: <1185920349.12650.4.camel@neutron.verbum.private> <1187021402.2998.12.camel@oneill.fubar.dk> <1187033932.2729.114.camel@localhost.localdomain> <1187034966.4921.28.camel@localhost.localdomain> <1187035831.6196.15.camel@oneill.fubar.dk> <20070827205443.GA23719@nostromo.devel.redhat.com> <1188314764.2737.22.camel@localhost.localdomain> Message-ID: <20070828174111.GC27876@nostromo.devel.redhat.com> Jonathan Blandford (jrb at redhat.com) said: > I think what David is getting at is that we would like to have only one > install experience for the user. Right now, we have two install > experiences -- the first when you run anaconda, the second when you hit > firstboot. In the managed desktop case (enterprise workstations) the > install is split between the admin who does the install on the machine > and the enduser does the 'install' by setting up accounts/timezones. > David is proposing to merge those for the desktop spin. > > It's a bit aspirational, and there's a lot that should be cleaned up in > firstboot first. But I think it's a good experience, too. What confuses me is that I'm not sure firstboot makes sense for any sort of 'managed' desktop - surely things like authentication, timezone, and users (on the network) have already been set up by that point? Firstboot seems more targeted for the 'home user' (ugh) who is getting a preinstalled box from some OEM. What may make sense (and also be completely unimplementable) is to structure things so that steps can be moved between firstboot and anaconda at will based on some sort of configuration. Bill From jkeating at redhat.com Tue Aug 28 17:52:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 28 Aug 2007 13:52:16 -0400 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <20070828174111.GC27876@nostromo.devel.redhat.com> References: <1185920349.12650.4.camel@neutron.verbum.private> <1187021402.2998.12.camel@oneill.fubar.dk> <1187033932.2729.114.camel@localhost.localdomain> <1187034966.4921.28.camel@localhost.localdomain> <1187035831.6196.15.camel@oneill.fubar.dk> <20070827205443.GA23719@nostromo.devel.redhat.com> <1188314764.2737.22.camel@localhost.localdomain> <20070828174111.GC27876@nostromo.devel.redhat.com> Message-ID: <20070828135216.761b2ff4@mentok.boston.redhat.com> On Tue, 28 Aug 2007 13:41:11 -0400 Bill Nottingham wrote: > What may make sense (and also be completely unimplementable) is to > structure things so that steps can be moved between firstboot and > anaconda at will based on some sort of configuration. Or we just drop some things from firstboot all together, move some (user creation) into anaconda, and then leave firstboot there as a possibility to be turned on and ran with say --reconfig which makes sense from the OEM point of view. -- 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 notting at redhat.com Tue Aug 28 18:15:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 28 Aug 2007 14:15:39 -0400 Subject: low-hanging fruit In-Reply-To: <1188232541.3135.0.camel@rousalka.dyndns.org> References: <1187207783.3319.27.camel@dhcp83-186.boston.redhat.com> <1188084235.3052.2.camel@hive> <1188222917.2365.5.camel@localhost.localdomain> <1188229613.3054.6.camel@hive> <1188232541.3135.0.camel@rousalka.dyndns.org> Message-ID: <20070828181539.GF27876@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > Le lundi 27 ao?t 2007 ? 16:46 +0100, Rui Tiago Ca??o Matos a ?crit : > > On Seg, 2007-08-27 at 09:55 -0400, Jeremy Katz wrote: > > > How was your filesystem created? anaconda has been doing this on ext3 > > > filesystems since we first started doing ext3 many years ago[1]. > > > > Ups, sorry for the noise then. This filesystem wasn't created by > > anaconda. I manually issued "tune2fs -c 0" on it now. > > Though one could argue the lowlevel ext2/ext3 tools should have another > default when creating a filesystem with a journal Could be set in mke2fs.conf - of course, that would apply to everything. Bill From jrb at redhat.com Wed Aug 29 17:44:56 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Wed, 29 Aug 2007 13:44:56 -0400 Subject: make ~/.face world-readable (low-hanging-fruit) (Was Re: livecd hacking) In-Reply-To: <20070828174111.GC27876@nostromo.devel.redhat.com> References: <1185920349.12650.4.camel@neutron.verbum.private> <1187021402.2998.12.camel@oneill.fubar.dk> <1187033932.2729.114.camel@localhost.localdomain> <1187034966.4921.28.camel@localhost.localdomain> <1187035831.6196.15.camel@oneill.fubar.dk> <20070827205443.GA23719@nostromo.devel.redhat.com> <1188314764.2737.22.camel@localhost.localdomain> <20070828174111.GC27876@nostromo.devel.redhat.com> Message-ID: <1188409496.2747.51.camel@localhost.localdomain> On Tue, 2007-08-28 at 13:41 -0400, Bill Nottingham wrote: > Jonathan Blandford (jrb at redhat.com) said: > > I think what David is getting at is that we would like to have only one > > install experience for the user. Right now, we have two install > > experiences -- the first when you run anaconda, the second when you hit > > firstboot. In the managed desktop case (enterprise workstations) the > > install is split between the admin who does the install on the machine > > and the enduser does the 'install' by setting up accounts/timezones. > > David is proposing to merge those for the desktop spin. > > > > It's a bit aspirational, and there's a lot that should be cleaned up in > > firstboot first. But I think it's a good experience, too. > > What confuses me is that I'm not sure firstboot makes sense for any > sort of 'managed' desktop - surely things like authentication, timezone, > and users (on the network) have already been set up by that point? Firstboot > seems more targeted for the 'home user' (ugh) who is getting a preinstalled > box from some OEM. It depends a bit on the enterprise doing the managing. Some of them do set timezones/users in advance, but most don't bother. Enough let the end user do it that I stand by my generalization. (-: Additionally, a non-trivial number of people add their own firstboot modules to the mix to set up site-specific stuff. > What may make sense (and also be completely unimplementable) is to structure > things so that steps can be moved between firstboot and anaconda at will > based on some sort of configuration. Yeah, though that's led to some of the awkward sharing of code and a few poor design. One thing we proposed doing is actually moving firstboot to be part of GDM, and letting things like the timezone and user accounts be modifiable from there. Thanks, -Jonathan From jon.nettleton at gmail.com Wed Aug 29 17:55:52 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 29 Aug 2007 13:55:52 -0400 Subject: Okay earlygdm re-tooled for a desktop spin Message-ID: Based on some urging from the community I decided to re-tool what I had and release a version of patches to it that could use the existing rhgb without any patches. You can download the svn diff here http://www.hekanetworks.com/~jnettlet/open-source/fedora/earlygdm.diff Before you just going and applying this patch to your system here are the working internals *!!!!* I have patched start_udev so it can be run in two separate pieces. So I had the necessary pieces to start X without waiting 7 seconds staring at starting udev *yawn* this was necessary. There is no reason we can't dupe start_udev into two individual files that doesn't touch the original file. I am open to doing that. I don't have init level checking in my code yet. It is simple to do I just haven't done it yet. I have gdm reading from a custom earlygdm.conf file so you can mess with that without changing your systems default behavior. One other patch just moves the acpi module installation to /etc/sysconfig/modules . Working the rc.sysinit I just kept seeing that there and had no idea why were weren't using the mechanism 10 lines above it. Right now this works seamlessly on my nvidia box, but my openchrome laptop is killing off the x-server before the gdm greeter has run. My guess is my laptop is slow enough that it is hitting one of gdm's timeout values and the slave is getting reset. Currently the manual fscking and such is not interactive because rhgb needs another fifo to send input back from it's vte to another program. I started writing this and then decided to wait until I found out what other people think. I am also toying with allowing rhgb to do gtk.embedding, or possibly create an overlay like gdm uses to run it's setup program, so the apps run in rc.sysinit if it is unconfigured can run their Xorg counterparts. I am also tempted to play around with Zenity to see what else we can do to remove the need for a terminal and give more intuitive dialogs easily. Jon From davidz at redhat.com Wed Aug 29 18:11:14 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 29 Aug 2007 14:11:14 -0400 Subject: no Desktop SIG meeting today Message-ID: <1188411074.3763.1.camel@oneill.fubar.dk> Hi, There is no meeting today; Matthias is out on vacation, Chris is dealing with fender bender and the rest of us didn't send out an agenda / organize it in time. Apologies. We'll meet next week; will be a good time to reflect on F8t2 and the road ahead bringing us to Fedora 8. Thanks, David From kmaraas at broadpark.no Thu Aug 30 22:30:51 2007 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Fri, 31 Aug 2007 00:30:51 +0200 Subject: PackageKit Misconceptions In-Reply-To: <20070822143250.0b2d3330@mentok.boston.redhat.com> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <20070822143250.0b2d3330@mentok.boston.redhat.com> Message-ID: <1188513051.2616.0.camel@localhost.localdomain> ons, 22.08.2007 kl. 14.32 -0400, skrev Jesse Keating: > On Wed, 22 Aug 2007 14:17:06 -0400 > "Colin Walters" wrote: > > > No one has really solved the problem of trojan software. Dialogs are > > definitely not a solution. Now, we can have a dialog for it and I > > wouldn't argue against it - but we shouldn't delude ourselves into > > thinking that having people enter a password is going to stop them > > from getting their MP3s to play. > > It's not about stopping them from getting mp3s, but whatever. > > "We want better dialogs that aren't technobabble". I agree > wholeheartedly. > > "We want to allow for (and default to) some level of auth before > allowing installing software/writing to outside your home dir". Again > in agreement. > > Your browser question is only so so. Sure you can install stuff to > your home dir, but you can't compromise other users on the system. > And for the desktop spin...how many other users are there on the system normally? Cheers Kjartan From jkeating at redhat.com Fri Aug 31 00:22:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 30 Aug 2007 20:22:52 -0400 Subject: PackageKit Misconceptions In-Reply-To: <1188513051.2616.0.camel@localhost.localdomain> References: <15e53e180708220946g546e1154re7bcf5e770334ba2@mail.gmail.com> <20070822133100.5f2daedb@mentok.boston.redhat.com> <20070822140113.3e9bd789@mentok.boston.redhat.com> <20070822143250.0b2d3330@mentok.boston.redhat.com> <1188513051.2616.0.camel@localhost.localdomain> Message-ID: <20070830202252.2b77b7cb@ender> On Fri, 31 Aug 2007 00:30:51 +0200 Kjartan Maraas wrote: > And for the desktop spin...how many other users are there on the > system normally? I don't know, I share my laptop with my family a lot for quick things. A home workstation is probably used by more than one member of the family. -- 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: