From esmac9 at hotmail.com Sat May 1 13:29:08 2004 From: esmac9 at hotmail.com (Steven Mackay) Date: Sat, 01 May 2004 13:29:08 +0000 Subject: GDM Suggestion Message-ID: Why doesn't someone add a "Make this my default" checkbox to the GDM session chooser? This would mean we could change our default desktop from the login screen and get rid of the Switchdesk utility altogether. And add this to KDM as well, of course. _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo From mattdm at mattdm.org Sat May 1 13:39:19 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 1 May 2004 09:39:19 -0400 Subject: GDM Suggestion In-Reply-To: References: Message-ID: <20040501133919.GA4525@jadzia.bu.edu> On Sat, May 01, 2004 at 01:29:08PM +0000, Steven Mackay wrote: > Why doesn't someone add a "Make this my default" checkbox to the GDM > session chooser? > This would mean we could change our default desktop from the login screen > and get rid of the Switchdesk utility altogether. > And add this to KDM as well, of course. Older versions of GDM asked you if you wanted to switch your session permanently. This seems to be gone now, and it tells you to run switchdesk -- someone seems to have made the opposite decision, that this functionality doesn't belong in GDM. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From hp at redhat.com Sat May 1 15:04:15 2004 From: hp at redhat.com (Havoc Pennington) Date: Sat, 01 May 2004 11:04:15 -0400 Subject: GDM Suggestion In-Reply-To: <20040501133919.GA4525@jadzia.bu.edu> References: <20040501133919.GA4525@jadzia.bu.edu> Message-ID: <1083423855.2242.4.camel@localhost.localdomain> On Sat, 2004-05-01 at 09:39, Matthew Miller wrote: > On Sat, May 01, 2004 at 01:29:08PM +0000, Steven Mackay wrote: > > Why doesn't someone add a "Make this my default" checkbox to the GDM > > session chooser? > > This would mean we could change our default desktop from the login screen > > and get rid of the Switchdesk utility altogether. > > And add this to KDM as well, of course. > > Older versions of GDM asked you if you wanted to switch your session > permanently. This seems to be gone now, and it tells you to run switchdesk > -- someone seems to have made the opposite decision, that this functionality > doesn't belong in GDM. > We were just trying to keep switchdesk working (I think this is a Red Hat patch to gdm), there was some elaborate rationale. There seemed to be some recent sentiment to just delete switchdesk and use the upstream gdm method. Havoc From helios82 at optushome.com.au Sat May 1 23:21:37 2004 From: helios82 at optushome.com.au (Matt Hansen) Date: Sun, 02 May 2004 09:21:37 +1000 Subject: GDM Suggestion In-Reply-To: <1083423855.2242.4.camel@localhost.localdomain> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> Message-ID: <1083453697.3572.20.camel@fc1> On Sun, 2004-05-02 at 01:04, Havoc Pennington wrote: > > We were just trying to keep switchdesk working (I think this is a Red > Hat patch to gdm), there was some elaborate rationale. There seemed to > be some recent sentiment to just delete switchdesk and use the upstream > gdm method. > > Havoc Seemed as in not any more or seemed as in you guys (Red Hat) are in the process of deciding whether to switch to upstream method? Maybe adding this back into GDM would help with bugs like the following no? http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121840 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121813 So, what was this "elaborate rationale" for keeping Red Hat's patch for using switchdesk? With switchdesk, I have never been able to add another WM to it's GUI (the ones in there are hardcoded?) but have been able to get an entry for it in the GDM session screen. Therefore, if there was an "Make default" on the GDM session screen, this should mean I could make the new WM permanent. Regards, -Matt -- "Would you buy a car with the hood welded shut?" - Bob Young on the benefits of the open source development model. mhelios - www.fedoraforum.org -------------- 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 hp at redhat.com Sun May 2 04:08:58 2004 From: hp at redhat.com (Havoc Pennington) Date: Sun, 02 May 2004 00:08:58 -0400 Subject: GDM Suggestion In-Reply-To: <1083453697.3572.20.camel@fc1> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> Message-ID: <1083470937.2242.41.camel@localhost.localdomain> On Sat, 2004-05-01 at 19:21, Matt Hansen wrote: > > Seemed as in not any more or seemed as in you guys (Red Hat) are in the > process of deciding whether to switch to upstream method? Seemed as in I remember some discussion along those lines but I don't know if anyone finally decided. > So, what was this "elaborate rationale" for keeping Red Hat's patch for > using switchdesk? I don't remember the whole set of issues but I think it was basically so that a) switchdesk would appear to do something (it only works if you are using the "Default" gdm session which runs ~/.Xclients, so if you'd chosen a session in gdm switchdesk would seem busted) and b) so that if someone had run switchdesk historically they wouldn't get reverted to the default desktop on upgrade. Part of the issue is that switchdesk works with startx and kdm, but I don't think we should care about that anymore honestly. kdm could have similar functionality, and in the startx case someone is using command line already and can edit .Xclients. Havoc From warren at togami.com Sun May 2 04:17:51 2004 From: warren at togami.com (Warren Togami) Date: Sat, 01 May 2004 18:17:51 -1000 Subject: pango should Requires: xorg-x11-base-fonts ? Message-ID: <4094766F.6080701@togami.com> No fonts found; this probably means that the fontconfig library is not correctly configured. You may need to edit the fonts.conf configuration file. More information about fontconfig can be found in the fontconfig(3) manual page and on http://fontconfig.org If you run any application that requires pango like gaim or dia and xorg-x11-base-fonts is not installed, then the above error message appears on the console and the application fails. Should it then be proper for pango to Requires: xorg-x11-base-fonts, or a generic equivalent that also works with XFree86? Does such a generic equivalent exist? Warren Togami wtogami at redhat.com From otaylor at redhat.com Sun May 2 14:32:56 2004 From: otaylor at redhat.com (Owen Taylor) Date: Sun, 02 May 2004 10:32:56 -0400 Subject: pango should Requires: xorg-x11-base-fonts ? In-Reply-To: <4094766F.6080701@togami.com> References: <4094766F.6080701@togami.com> Message-ID: <1083508375.23877.4.camel@localhost.localdomain> On Sun, 2004-05-02 at 00:17, Warren Togami wrote: > No fonts found; this probably means that the fontconfig > library is not correctly configured. You may need to > edit the fonts.conf configuration file. More information > about fontconfig can be found in the fontconfig(3) manual > page and on http://fontconfig.org > > If you run any application that requires pango like gaim or dia and > xorg-x11-base-fonts is not installed, then the above error message > appears on the console and the application fails. > > Should it then be proper for pango to Requires: xorg-x11-base-fonts, or > a generic equivalent that also works with XFree86? Does such a generic > equivalent exist? Well, *ANY* fonts will satisfy the requirement. urw-fonts, bitmap-fonts, fonts-bengali. You'll only get that warning if you literally have no fonts installed. How did you manage that? I don't really know what fonts are packaged where in the xorg-x11 packages so I can't make a recommendation as to what (if any) fonts we might want the Pango package to require. (But you could ask, why Pango in particular... requiring some fonts to operate is not at all particular to it; we use fontconfig and Xft in various non-Pango based programs including all of KDE) The default fontconfig configuration we ship prefers a combination of Luxi and URW fonts. Regards, Owen -------------- 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 otaylor at redhat.com Sun May 2 14:40:56 2004 From: otaylor at redhat.com (Owen Taylor) Date: Sun, 02 May 2004 10:40:56 -0400 Subject: GDM Suggestion In-Reply-To: <1083470937.2242.41.camel@localhost.localdomain> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> Message-ID: <1083508855.23877.13.camel@localhost.localdomain> On Sun, 2004-05-02 at 00:08, Havoc Pennington wrote: > 't remember the whole set of issues but I think it was basically so > that a) switchdesk would appear to do something (it only works if you > are using the "Default" gdm session which runs ~/.Xclients, so if you'd > chosen a session in gdm switchdesk would seem busted) and b) so that if > someone had run switchdesk historically they wouldn't get reverted to > the default desktop on upgrade. > > Part of the issue is that switchdesk works with startx and kdm, but I > don't think we should care about that anymore honestly. kdm could have > similar functionality, and in the startx case someone is using command > line already and can edit .Xclients. Nothing elaborate about the rational: - At that time we supported xdm, kdm, gdm, and startx - So we needed something like switchdesk - The combination of switchdesk and gdm choosing the session doesn't work correctly. Regards, Owen -------------- 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 duncanbrown at linuxadvocate.net Mon May 3 15:22:18 2004 From: duncanbrown at linuxadvocate.net (duncan brown) Date: Mon, 3 May 2004 11:22:18 -0400 (EDT) Subject: GDM Suggestion In-Reply-To: <1083508855.23877.13.camel@localhost.localdomain> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> Message-ID: <53222.192.58.199.187.1083597738.squirrel@atom.csionline.net> Owen Taylor said: > On Sun, 2004-05-02 at 00:08, Havoc Pennington wrote: > > Nothing elaborate about the rational: > > - At that time we supported xdm, kdm, gdm, and startx > - So we needed something like switchdesk > - The combination of switchdesk and gdm choosing the session doesn't > work correctly. personally, i think that the login manager shouldn't be gtk/qt/etc specific, but very much neutral as to not add requirements to the install that shouldn't have to be there. -d -+(duncan brown -+(duncanbrown at linuxadvocate.net -+(http://www.linuxadvocate.net () ascii ribbon campaign - against html e-mail /\ - against microsoft attachments Blessed is the man who, having nothing to say, abstains from giving wordy evidence of the fact. -- George Eliot From hp at redhat.com Mon May 3 15:55:05 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 03 May 2004 11:55:05 -0400 Subject: GDM Suggestion In-Reply-To: <53222.192.58.199.187.1083597738.squirrel@atom.csionline.net> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> <53222.192.58.199.187.1083597738.squirrel@atom.csionline.net> Message-ID: <1083599705.2102.37.camel@localhost.localdomain> On Mon, 2004-05-03 at 11:22, duncan brown wrote: > > personally, i think that the login manager shouldn't be gtk/qt/etc > specific, but very much neutral as to not add requirements to the install > that shouldn't have to be there. All UI has to use a toolkit or it flunks a whole series of requirements (i18n, a11y, for starters). Any controls that aren't using GTK or Qt are a bug, though in some cases they're a legacy bug we'll never care to fix (e.g. "classic X" apps such as xterm). Havoc From markmc at redhat.com Mon May 3 21:46:54 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 03 May 2004 22:46:54 +0100 Subject: GDM Suggestion In-Reply-To: <1083508855.23877.13.camel@localhost.localdomain> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> Message-ID: <1083620813.1995.19.camel@laptop> Hey, On Sun, 2004-05-02 at 15:40, Owen Taylor wrote: > On Sun, 2004-05-02 at 00:08, Havoc Pennington wrote: > > > 't remember the whole set of issues but I think it was basically so > > that a) switchdesk would appear to do something (it only works if you > > are using the "Default" gdm session which runs ~/.Xclients, so if you'd > > chosen a session in gdm switchdesk would seem busted) and b) so that if > > someone had run switchdesk historically they wouldn't get reverted to > > the default desktop on upgrade. > > > > Part of the issue is that switchdesk works with startx and kdm, but I > > don't think we should care about that anymore honestly. kdm could have > > similar functionality, and in the startx case someone is using command > > line already and can edit .Xclients. > > Nothing elaborate about the rational: > > - At that time we supported xdm, kdm, gdm, and startx > - So we needed something like switchdesk > - The combination of switchdesk and gdm choosing the session doesn't > work correctly. So, the conclusion I draw from that is that we should just get rid of switchdesk. It'd be great if someone could log a bug to do that and another bug to get rid of the switchdesk specific code from GDM. (Btw, if you do rpm --erase switchdesk, you should get the "old" GDM functionality for switching desktops) Cheers, Mark. From notting at redhat.com Mon May 3 21:50:52 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 3 May 2004 17:50:52 -0400 Subject: GDM Suggestion In-Reply-To: <1083620813.1995.19.camel@laptop> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> <1083620813.1995.19.camel@laptop> Message-ID: <20040503215052.GA1793@nostromo.devel.redhat.com> Mark McLoughlin (markmc at redhat.com) said: > So, the conclusion I draw from that is that we should just get rid of > switchdesk. I actually thought that was the solution a while back - the only place this doesn't help is the startx case. Bill From laroche at redhat.com Mon May 3 21:55:18 2004 From: laroche at redhat.com (Florian La Roche) Date: Mon, 3 May 2004 23:55:18 +0200 Subject: GDM Suggestion In-Reply-To: <20040503215052.GA1793@nostromo.devel.redhat.com> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> <1083620813.1995.19.camel@laptop> <20040503215052.GA1793@nostromo.devel.redhat.com> Message-ID: <20040503215518.GA20247@dudweiler.stuttgart.redhat.com> On Mon, May 03, 2004 at 05:50:52PM -0400, Bill Nottingham wrote: > Mark McLoughlin (markmc at redhat.com) said: > > So, the conclusion I draw from that is that we should just get rid of > > switchdesk. > > I actually thought that was the solution a while back - the only place > this doesn't help is the startx case. gdm is now handling Gnome/KDE, but shouldn't switchdesk still allow for changing startx default values? I think I have still seen strong requests to keep that functionality. greetings, Florian La Roche From hp at redhat.com Mon May 3 22:10:10 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 03 May 2004 18:10:10 -0400 Subject: GDM Suggestion In-Reply-To: <20040503215052.GA1793@nostromo.devel.redhat.com> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> <1083620813.1995.19.camel@laptop> <20040503215052.GA1793@nostromo.devel.redhat.com> Message-ID: <1083622210.3438.30.camel@localhost.localdomain> On Mon, 2004-05-03 at 17:50, Bill Nottingham wrote: > > I actually thought that was the solution a while back - the only place > this doesn't help is the startx case. startx is a command line thing though, which means startx users are perfectly capable of editing .Xclients themselves instead of with switchdesk. Just document how to start each desktop in .Xclients... Havoc From notting at redhat.com Mon May 3 22:15:23 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 3 May 2004 18:15:23 -0400 Subject: GDM Suggestion In-Reply-To: <1083622210.3438.30.camel@localhost.localdomain> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> <1083620813.1995.19.camel@laptop> <20040503215052.GA1793@nostromo.devel.redhat.com> <1083622210.3438.30.camel@localhost.localdomain> Message-ID: <20040503221523.GB3469@nostromo.devel.redhat.com> Havoc Pennington (hp at redhat.com) said: > On Mon, 2004-05-03 at 17:50, Bill Nottingham wrote: > > > > I actually thought that was the solution a while back - the only place > > this doesn't help is the startx case. > > startx is a command line thing though, which means startx users are > perfectly capable of editing .Xclients themselves instead of with > switchdesk. Just document how to start each desktop in .Xclients... If you do that, might as well have GDM edit it for you. Bill From duncanbrown at linuxadvocate.net Tue May 4 00:34:50 2004 From: duncanbrown at linuxadvocate.net (duncan brown) Date: Mon, 3 May 2004 20:34:50 -0400 (EDT) Subject: GDM Suggestion In-Reply-To: <1083620813.1995.19.camel@laptop> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> <1083620813.1995.19.camel@laptop> Message-ID: <50321.138.88.168.45.1083630890.squirrel@atom.csionline.net> Mark McLoughlin said: > (Btw, if you do rpm --erase switchdesk, you should get the "old" GDM > functionality for switching desktops) you won't really have gdm at all. -d [root at crazybastard root]# yum remove switchdesk Gathering header information file(s) from server(s) Server: fedora core 1 :: fedora base Server: fedora core 1 :: fedora updates Server: fedora core :: linuxadvocate.net Finding updated packages Downloading needed headers kernel-BOOT-0-2.4.22-1.21 100% |=========================| 23 kB 00:00 kernel-smp-0-2.4.22-1.218 100% |=========================| 42 kB 00:00 kernel-doc-0-2.4.22-1.218 100% |=========================| 26 kB 00:00 kernel-0-2.4.22-1.2188.np 100% |=========================| 42 kB 00:00 kernel-smp-0-2.4.22-1.218 100% |=========================| 43 kB 00:00 mc-1-4.6.0-14.10.i386.hdr 100% |=========================| 12 kB 00:00 kernel-0-2.4.22-1.2188.np 100% |=========================| 41 kB 00:00 Resolving dependencies .......Dependencies resolved I will do the following: [erase: switchdesk 3.9.8-18.i386] I will erase these to satisfy the dependencies: [deps: gdm 1:2.4.4.5-1.2.i386] [deps: libgnomeprintui22 2.4.0-1.i386] [deps: redhat-config-xfree86 0.9.15-1.noarch] [deps: libgal2 2:1.99.10-2.i386] [deps: nautilus-media 0.3.1-1.i386] [deps: XFree86-xdm 4.3.0-55.i386] [deps: k3b 0.11.9-0.fdr.1.1.i386] [deps: evolution 1.4.5-7.i386] [deps: libgnomeprintui 1.116.0-5.i386] [deps: XFree86-twm 4.3.0-55.i386] [deps: xinitrc 3.35-1.noarch] [deps: control-center 1:2.4.0-3.i386] [deps: XFree86 4.3.0-55.i386] [deps: kdebase 6:3.1.4-6.i386] [deps: gthumb 2.0.2-1.i386] [deps: openoffice.org 1.1.0-16.i386] [deps: mrproject 0.10-1.i386] [deps: gedit 1:2.4.0-3.i386] [deps: libgnomeprint 1.116.0-7.i386] [deps: nautilus 2.4.0-7.i386] [deps: XFree86-tools 4.3.0-55.i386] [deps: gtkhtml3 3.0.9-5.i386] [deps: gtksourceview 0.6.0-2.i386] [deps: gpdf 0.110-1.i386] [deps: libgnomeprint22 2.4.0-1.i386] [deps: eog 2.4.0-1.i386] [deps: gnome-session 2.4.0-3.i386] Is this ok [y/N]: +( duncan brown : duncanbrown at linuxadvocate.net )+ +( linux "just works" : www.linuxadvocate.net )+ -------------------------------------------------- Understatement of the century: "Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones" - Linus Torvalds, August 1991 -------------------------------------------------- From skvidal at phy.duke.edu Tue May 4 00:42:46 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 03 May 2004 20:42:46 -0400 Subject: GDM Suggestion In-Reply-To: <50321.138.88.168.45.1083630890.squirrel@atom.csionline.net> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> <1083620813.1995.19.camel@laptop> <50321.138.88.168.45.1083630890.squirrel@atom.csionline.net> Message-ID: <1083631366.25635.41.camel@binkley> On Mon, 2004-05-03 at 20:34 -0400, duncan brown wrote: > Mark McLoughlin said: > > (Btw, if you do rpm --erase switchdesk, you should get the "old" GDM > > functionality for switching desktops) > > you won't really have gdm at all. I think he meant from fedora core 2 test 3, not from fedora core 1. -sv From link at subpop.net Tue May 4 04:38:36 2004 From: link at subpop.net (Link Dupont) Date: Mon, 03 May 2004 21:38:36 -0700 Subject: Bluecurve Thunderbird theme Message-ID: <40971E4C.2000702@subpop.net> Hello Fedora fans, I've noticed Garrett's screenshot of Mozilla Thunderbird, and I'm wondering of there's ever been any movement to make a Bluecurve theme for Thunderbird. I believe there's been some discussion on making a Bluecurve Firefox theme, and I think it'd be cool to have a complimenting Thunderbird theme too. Sound like a nice idea? -- Link Dupont From foolish at guezz.net Tue May 4 14:32:38 2004 From: foolish at guezz.net (Sindre Pedersen Bjordal) Date: Tue, 04 May 2004 16:32:38 +0200 Subject: Bluecurve Thunderbird theme In-Reply-To: <40971E4C.2000702@subpop.net> References: <40971E4C.2000702@subpop.net> Message-ID: <1083681157.7311.13.camel@localhost.localdomain> tir, 04.05.2004 kl. 06.38 skrev Link Dupont: > Hello Fedora fans, > I've noticed Garrett's screenshot of Mozilla Thunderbird, and I'm > wondering of there's ever been any movement to make a Bluecurve theme > for Thunderbird. I believe there's been some discussion on making a > Bluecurve Firefox theme, and I think it'd be cool to have a > complimenting Thunderbird theme too. Sound like a nice idea? > -- > Link Dupont > Very good idea, I think we should have everything in Bluecurve if possible, and its should be so by default. Making the desktop consistent is important, and it really does give the user a feel of a polished distro. However I think the applications that are part of the distro should get themed first. I notice how openoffice.org has received some Bluecurve love in core 2, which is really great. It feels like part of the desktop now. Getting Mozilla a Bluecurve theme is long over due. Actually one already exists, and I can't understand why we don't have the wonderful Mozilla Bluecurve theme, mozcurveblue, by Gavindi, in Fedora by default yet. I know he would like to see it in there. See http://users.bigpond.net.au/gavindi/ The default Mozilla theme looks very old, and doesn't integrate very well with the rest of the desktop, making Mozilla seem like some app just thrown in there, and not part of the otherwise excellent user experience. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From mdraghi at prosud.com Tue May 4 14:48:55 2004 From: mdraghi at prosud.com (Mariano Draghi) Date: Tue, 04 May 2004 11:48:55 -0300 Subject: Bluecurve Thunderbird theme In-Reply-To: <1083681157.7311.13.camel@localhost.localdomain> References: <40971E4C.2000702@subpop.net> <1083681157.7311.13.camel@localhost.localdomain> Message-ID: Sindre Pedersen Bjordal escribi?: > > Getting Mozilla a Bluecurve theme is long over due. Actually one already > exists, and I can't understand why we don't have the wonderful Mozilla > Bluecurve theme, mozcurveblue, by Gavindi, in Fedora by default yet. I > know he would like to see it in there. See > http://users.bigpond.net.au/gavindi/ > Yes! I asked about this some time ago... That theme is _perfect_ Plesase, is there anything we can do to get this in the official Fedora's Mozilla build? I've been using this for months, w/o any problem. Regards, -- Mariano From privat at trond-danielsen.org Tue May 4 19:38:04 2004 From: privat at trond-danielsen.org (Trond Danielsen) Date: Tue, 04 May 2004 21:38:04 +0200 Subject: Bluecurve Thunderbird theme In-Reply-To: References: <40971E4C.2000702@subpop.net> <1083681157.7311.13.camel@localhost.localdomain> Message-ID: <4097F11C.2030600@trond-danielsen.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mariano Draghi wrote: | Sindre Pedersen Bjordal escribi?: | |> |> Getting Mozilla a Bluecurve theme is long over due. Actually one already |> exists, and I can't understand why we don't have the wonderful Mozilla |> Bluecurve theme, mozcurveblue, by Gavindi, in Fedora by default yet. I |> know he would like to see it in there. See |> http://users.bigpond.net.au/gavindi/ |> | | Yes! I asked about this some time ago... That theme is _perfect_ | Plesase, is there anything we can do to get this in the official | Fedora's Mozilla build? | I've been using this for months, w/o any problem. | | Regards, | Got a small question, hope it's not out of line. Tried the theme with firefox, but it didn't work. Is it a problem "porting" it to firefox, and where can I find directions howto? - -- Trond Danielsen *********************************** _ * http://www.trond-danielsen.org * The ASCII ribbon campaign ( ) * Mobile tlf: +47 99 62 52 35 * against HTML e-mail X * GPG ID: 0x02F29FD9 * http://www.metacon.ca/ascii / \ *********************************** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAl/EbrHrsMALyn9kRAo4AAKCZAekK4X2pJ605HZeXIFKUUSEQjQCfWIw0 qvNuGdD+0lZf4m5J1fzAF7Y= =W9Fq -----END PGP SIGNATURE----- From foolish at guezz.net Tue May 4 19:47:22 2004 From: foolish at guezz.net (Sindre Pedersen Bjordal) Date: Tue, 04 May 2004 21:47:22 +0200 Subject: Bluecurve Thunderbird theme In-Reply-To: <4097F11C.2030600@trond-danielsen.org> References: <40971E4C.2000702@subpop.net> <1083681157.7311.13.camel@localhost.localdomain> <4097F11C.2030600@trond-danielsen.org> Message-ID: <1083700041.9350.3.camel@localhost.localdomain> tir, 04.05.2004 kl. 21.38 skrev Trond Danielsen: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mariano Draghi wrote: > | Sindre Pedersen Bjordal escribi?: > | > |> > |> Getting Mozilla a Bluecurve theme is long over due. Actually one already > |> exists, and I can't understand why we don't have the wonderful Mozilla > |> Bluecurve theme, mozcurveblue, by Gavindi, in Fedora by default yet. I > |> know he would like to see it in there. See > |> http://users.bigpond.net.au/gavindi/ > |> > | > | Yes! I asked about this some time ago... That theme is _perfect_ > | Plesase, is there anything we can do to get this in the official > | Fedora's Mozilla build? > | I've been using this for months, w/o any problem. > | > | Regards, > | > Got a small question, hope it's not out of line. Tried the theme with > firefox, but it didn't work. Is it a problem "porting" it to firefox, > and where can I find directions howto? > > - -- > Trond Danielsen > See the firefox f.a.q: http://texturizer.net/firefox/faq.html#createtheme -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From mdraghi at prosud.com Tue May 4 19:56:21 2004 From: mdraghi at prosud.com (Mariano Draghi) Date: Tue, 04 May 2004 16:56:21 -0300 Subject: Bluecurve Thunderbird theme In-Reply-To: <4097F11C.2030600@trond-danielsen.org> References: <40971E4C.2000702@subpop.net> <1083681157.7311.13.camel@localhost.localdomain> <4097F11C.2030600@trond-danielsen.org> Message-ID: Trond Danielsen escribi?: > | Sindre Pedersen Bjordal escribi?: > | > |> > |> [ ... snip ... ] > |> http://users.bigpond.net.au/gavindi/ > |> > | > Got a small question, hope it's not out of line. Tried the theme with > firefox, but it didn't work. Is it a problem "porting" it to firefox, > and where can I find directions howto? As far as I know, the (above) mentioned theme is for Mozilla (aka Seamonkey). I'm afraid Mozilla themes aren't compatible with the Firefox/Thunderbird ones. You should ask the developer (Gavindi) for a port, or wait and see if something comes out from Fedora itself... there is some work being done. Or at least that was said some time ago... See: http://www.redhat.com/archives/fedora-desktop-list/2004-March/msg00047.html http://www.redhat.com/archives/fedora-desktop-list/2004-March/msg00048.html Regards, -- Mariano From stuart at terminus.co.uk Wed May 5 01:14:36 2004 From: stuart at terminus.co.uk (Stuart Children) Date: Wed, 05 May 2004 02:14:36 +0100 Subject: GDM Suggestion In-Reply-To: <20040503221523.GB3469@nostromo.devel.redhat.com> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> <1083620813.1995.19.camel@laptop> <20040503215052.GA1793@nostromo.devel.redhat.com> <1083622210.3438.30.camel@localhost.localdomain> <20040503221523.GB3469@nostromo.devel.redhat.com> Message-ID: <1083719675.4190.159.camel@hex.home.terminus.co.uk> To start off, one thing that's annoying about switchdesk is that it uses a hardcoded list of window managers. Really, it should use the sessions contained in /etc/X11/dm/ like gdm does. Obviously for the purpose of updating Xclients, any session with an Exec of default, custom, or failsafe should not be listed. I am willing to do this work. Two other things that could be done to improve matters regardless: Firstly, create some easier to find documentation on the whole X startup process. This would include the differences between what gdm and startx do. I have a small document on this which explains what happens on a Fedora system, and would be happy to tidy it up and contribute it to the documentation project (if someone can point out where it might be most useful). Secondly, the naming of the "Default" session is confusing. I would prefer that we added a proper "Custom" session. Xsession already allows this, but currently behaves the same for either. I would propose that the "default" action should execute /etc/X11/xinit/Xclients only (ie: it bypasses anything the user has set). The "custom" action should be what executes your own startup files. The long descriptions of these two sessions should make it clear what they do. Eg: "Default system session - ignores any custom session"; "Custom session set in ~/.Xclients". Obviously there's the concern about backwards compatibility - especially as the current way of doing things means there are more people using "default" than there would otherwise be. An aside: I would like to see a "failsafe" session available in the gdm selection. It just requires a session file with that as the Exec - the necessary code is already in Xsession. On Mon, 2004-05-03 at 23:15, Bill Nottingham wrote: > Havoc Pennington (hp at redhat.com) said: > > startx is a command line thing though, which means startx users are > > perfectly capable of editing .Xclients themselves instead of with > > switchdesk. Just document how to start each desktop in .Xclients... Speaking for myself - that would be acceptable. > If you do that, might as well have GDM edit it for you. Definitely a good option - only one tool to worry about. There are two issues though. Firstly, users who do not run a DM yet still want a tool to change their default session [for startx]. Secondly, users who want one default session for gdm, and another for startx. If both of those groups are deemed to be capable of editing Xclients by hand then the simplest solution to please the most people is to drop switchdesk, re-enable the gdm session selection code, and make it write Xclients. Alternatively we need to address the confusion caused by the combination of using switchdesk and gdm. If you set a default in gdm, it's not what gets used when you run startx. If you set a default in switchdesk, it's only used by gdm when "Default" is set there. I think the issue is that there are two tasks - choosing a session for gdm, and choosing a session for startx. For former is handled fine at login time by gdm's own code (currently disabled). The problem is really when someone wants to change the gdm session whilst logged in. They use switchdesk - but switchdesk is really designed for the other task, namely choosing a session for startx. I propose we solve this by making switchdesk suitable for both tasks - so it updates gdm (ie: set the appropriate gconf key) as well as startx (ie: writes ~/.Xclients). The default would be to change the setting of both, but you should be able to do one or the other. Obviously this requires my initial proposal (that switchdesk uses the same session list as gdm). There are varying ways you could do the UI for this - I'll try to mock up some ideas tomorrow. Again, I am willing to do the coding on this! Comments and ideas welcome. -- Stuart From kardarisk at upnet.gr Wed May 5 11:44:06 2004 From: kardarisk at upnet.gr (kardarisk at upnet.gr) Date: Wed, 5 May 2004 14:44:06 +0300 Subject: Bluecurve Thunderbird theme In-Reply-To: References: <40971E4C.2000702@subpop.net> <1083681157.7311.13.camel@localhost.localdomain> <4097F11C.2030600@trond-danielsen.org> Message-ID: <1083757446.4098d38681256@www.math.upatras.gr> On Tuesday, 4 May 2004, Mariano Draghi wrote: > Trond Danielsen escribi?: > > > | Sindre Pedersen Bjordal escribi?: > > | > > |> > > |> [ ... snip ... ] > > |> http://users.bigpond.net.au/gavindi/ > > |> > > | > > Got a small question, hope it's not out of line. Tried the theme > with > > firefox, but it didn't work. Is it a problem "porting" it to > firefox, > > and where can I find directions howto? > > As far as I know, the (above) mentioned theme is for Mozilla (aka > Seamonkey). I'm afraid Mozilla themes aren't compatible with the > Firefox/Thunderbird ones. > You should ask the developer (Gavindi) for a port, or wait and see if > > something comes out from Fedora itself... there is some work being > done. > Or at least that was said some time ago... > > See: > http://www.redhat.com/archives/fedora-desktop-list/2004-March/msg00047.html > http://www.redhat.com/archives/fedora-desktop-list/2004-March/msg00048.html > > Regards, > http://home.comcast.net/~lynchknot/fthemes.html hallo 2 every1 From wcohen at redhat.com Wed May 5 21:11:27 2004 From: wcohen at redhat.com (Will Cohen) Date: Wed, 05 May 2004 17:11:27 -0400 Subject: Performance tuning the Fedora Desktop Message-ID: <4099587F.4010200@redhat.com> I work on performance tools at Red Hat. I have been told there is interest in tuning the desktop to improve performance. I have a number of questions to help identify the work needed in this area. I would be interested in any answers that people have for the following questions. What is the set of software in the "Desktop" (executable names and/or RPM packages)? What specific performance problems have people observed so far in the desktop? For example heavy CPU or memory usage by particular applications. Another example long latency between event and resulting action. What metrics were used to gauged the effect of software changes on performance? What performance tools have people used so far to identify performance problems with desktop applications? How well or poorly did the performance tools work in identifying the performance problem? Were benchmarks used to test performance of desktop applications? If so, what type of benchmarks were used (e.g. micro benchmarks or measuring the amount of time required to do something in an application program)? Were the benchmarks runnable in batch mode without human assistance? -Will From lists at edmack.com Wed May 5 21:21:59 2004 From: lists at edmack.com (Ed Mack) Date: Wed, 05 May 2004 22:21:59 +0100 Subject: Performance tuning the Fedora Desktop In-Reply-To: <4099587F.4010200@redhat.com> References: <4099587F.4010200@redhat.com> Message-ID: <1083792119.4936.122.camel@localhost.localdomain> As a small note, I've found gaim to take a very excessive amount of time to bring up it's first connecting dialogue. Although, does this more fall into Gaim's domain? On Wed, 2004-05-05 at 22:11, Will Cohen wrote: > I work on performance tools at Red Hat. I have been told there is > interest in tuning the desktop to improve performance. I have a number > of questions to help identify the work needed in this area. I would be > interested in any answers that people have for the following questions. > > > What is the set of software in the "Desktop" (executable names and/or > RPM packages)? > > What specific performance problems have people observed so far in the > desktop? For example heavy CPU or memory usage by particular > applications. Another example long latency between event and resulting > action. > > What metrics were used to gauged the effect of software changes on > performance? > > What performance tools have people used so far to identify performance > problems with desktop applications? > > How well or poorly did the performance tools work in identifying the > performance problem? > > Were benchmarks used to test performance of desktop applications? If > so, what type of benchmarks were used (e.g. micro benchmarks or > measuring the amount of time required to do something in an > application program)? > > Were the benchmarks runnable in batch mode without human assistance? > > > -Will > > From kardarisk at upnet.gr Wed May 5 21:30:42 2004 From: kardarisk at upnet.gr (kardarisk at upnet.gr) Date: Thu, 6 May 2004 00:30:42 +0300 Subject: Performance tuning the Fedora Desktop In-Reply-To: <4099587F.4010200@redhat.com> References: <4099587F.4010200@redhat.com> Message-ID: <1083792641.40995d02008a4@www.math.upatras.gr> On Thursday, 6 May 2004, Will Cohen wrote: > I work on performance tools at Red Hat. I have been told there is > interest in tuning the desktop to improve performance. I have a > number > of questions to help identify the work needed in this area. I would > be > interested in any answers that people have for the following > questions. > > > What is the set of software in the "Desktop" (executable names > and/or > RPM packages)? > > What specific performance problems have people observed so far in > the > desktop? For example heavy CPU or memory usage by particular > applications. Another example long latency between event and > resulting > action. > > What metrics were used to gauged the effect of software changes on > performance? > > What performance tools have people used so far to identify > performance > problems with desktop applications? > > How well or poorly did the performance tools work in identifying > the > performance problem? > > Were benchmarks used to test performance of desktop applications? > If > so, what type of benchmarks were used (e.g. micro benchmarks or > measuring the amount of time required to do something in an > application program)? > > Were the benchmarks runnable in batch mode without human > assistance? > > > -Will > > > I think that up2date needs an optimization. More info later... From bri3d at sisna.com Fri May 7 12:10:33 2004 From: bri3d at sisna.com (Brian Ledbetter) Date: Fri, 7 May 2004 06:10:33 -0600 Subject: Performance tuning the Fedora Desktop In-Reply-To: <20040506160007.1C3CB741A5@hormel.redhat.com> References: <20040506160007.1C3CB741A5@hormel.redhat.com> Message-ID: <8A44B92A-A01F-11D8-A0B0-000393ADF4E8@sisna.com> As many others have pointed out rythymbox uses insane amounts of RAM after about one day of use. On May 6, 2004, at 10:00 AM, fedora-desktop-list-request at redhat.com wrote: > > From: Will Cohen > Date: May 5, 2004 3:11:27 PM MDT > To: fedora-desktop-list at redhat.com > Subject: Performance tuning the Fedora Desktop > Reply-To: Discussions about development for the Fedora desktop > > > > I work on performance tools at Red Hat. I have been told there is > interest in tuning the desktop to improve performance. I have a number > of questions to help identify the work needed in this area. I would be > interested in any answers that people have for the following > questions. > > > What is the set of software in the "Desktop" (executable names and/or > RPM packages)? > > What specific performance problems have people observed so far in the > desktop? For example heavy CPU or memory usage by particular > applications. Another example long latency between event and resulting > action. > > What metrics were used to gauged the effect of software changes on > performance? > > What performance tools have people used so far to identify performance > problems with desktop applications? > > How well or poorly did the performance tools work in identifying the > performance problem? > > Were benchmarks used to test performance of desktop applications? If > so, what type of benchmarks were used (e.g. micro benchmarks or > measuring the amount of time required to do something in an > application program)? > > Were the benchmarks runnable in batch mode without human assistance? > > > -Will -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1900 bytes Desc: not available URL: From walters at redhat.com Fri May 7 12:31:12 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 07 May 2004 08:31:12 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <8A44B92A-A01F-11D8-A0B0-000393ADF4E8@sisna.com> References: <20040506160007.1C3CB741A5@hormel.redhat.com> <8A44B92A-A01F-11D8-A0B0-000393ADF4E8@sisna.com> Message-ID: <1083933056.31543.13.camel@nexus.verbum.private> On Fri, 2004-05-07 at 08:10, Brian Ledbetter wrote: > As many others have pointed out rythymbox uses insane amounts of > RAMafter about one day of use. I can reproduce this now, and I'm working on tracking it down. -------------- 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 dh at iucr.org Fri May 7 14:54:07 2004 From: dh at iucr.org (David Holden) Date: Fri, 7 May 2004 15:54:07 +0100 Subject: Performance tuning the Fedora Desktop In-Reply-To: <4099587F.4010200@redhat.com> References: <4099587F.4010200@redhat.com> Message-ID: <200405071554.07366.dh@iucr.org> On Wednesday 05 May 2004 22:11, Will Cohen wrote: > I work on performance tools at Red Hat. I have been told there is > interest in tuning the desktop to improve performance. I have a number > of questions to help identify the work needed in this area. I would be > interested in any answers that people have for the following questions. > > > What is the set of software in the "Desktop" (executable names and/or > RPM packages)? > >From my point of view rpm -qa | grep kde would give a good starting list + emacs + java + mozilla (now seems faster than firefox strangely enough) > What specific performance problems have people observed so far in the > desktop? For example heavy CPU or memory usage by particular > applications. Another example long latency between event and resulting > action. heavy disk usage kill my machines performance, I work on a laptop with a fast CPU and plenty of ram. > > What metrics were used to gauged the effect of software changes on > performance? One point I will note is that KDE seems a lot speedier now I've upgraded to 3.2 line. Dave. > > What performance tools have people used so far to identify performance > problems with desktop applications? > > How well or poorly did the performance tools work in identifying the > performance problem? > > Were benchmarks used to test performance of desktop applications? If > so, what type of benchmarks were used (e.g. micro benchmarks or > measuring the amount of time required to do something in an > application program)? > > Were the benchmarks runnable in batch mode without human assistance? > > > -Will -- Dr. David Holden. (Systems Developer) Crystallography Journals Online: Thanks in advance:- Please avoid sending me Word or PowerPoint attachments. See: UK Privacy (R.I.P) : http://www.stand.org.uk/commentary.php3 Public GPG key available on request. ------------------------------------------------------------- From julo at altern.org Fri May 7 15:08:31 2004 From: julo at altern.org (Julien Olivier) Date: Fri, 07 May 2004 16:08:31 +0100 Subject: Performance tuning the Fedora Desktop In-Reply-To: <4099587F.4010200@redhat.com> References: <4099587F.4010200@redhat.com> Message-ID: <1083942511.3362.5.camel@julien> On Wed, 2004-05-05 at 22:11, Will Cohen wrote: > I work on performance tools at Red Hat. I have been told there is > interest in tuning the desktop to improve performance. I have a number > of questions to help identify the work needed in this area. I would be > interested in any answers that people have for the following questions. > > > What is the set of software in the "Desktop" (executable names and/or > RPM packages)? > > What specific performance problems have people observed so far in the > desktop? For example heavy CPU or memory usage by particular > applications. Another example long latency between event and resulting > action. > > What metrics were used to gauged the effect of software changes on > performance? > > What performance tools have people used so far to identify performance > problems with desktop applications? > > How well or poorly did the performance tools work in identifying the > performance problem? > > Were benchmarks used to test performance of desktop applications? If > so, what type of benchmarks were used (e.g. micro benchmarks or > measuring the amount of time required to do something in an > application program)? > > Were the benchmarks runnable in batch mode without human assistance? > > > -Will Here is a quick list of apps that seem to take too long to start for me: openoffice.org gedit gnome-terminal gnome-background-properties And, from time to time, clicking on the main menu takes ages to display the menu (where ages really mean up to 10 seconds) Hope this helps a little... -- Julien Olivier From opamp1 at telus.net Fri May 7 15:53:06 2004 From: opamp1 at telus.net (mace) Date: Fri, 07 May 2004 09:53:06 -0600 Subject: Core 2 test 3 display problem Message-ID: <409BB0E2.80101@telus.net> Hi, I have just installed core2 test 3. The system defaults to 640x480 for the screen resolution. I have tried changing it, reboot, and it stays at 640. When I go back into display, it shows the changed in resolution. Is this a bug or am I doing something wrong. Under preferences for display it only shows 640x480. I am running a tyan s2466 motherboard with dual mp2200+ 512 meg ram 60gig hd, Ati 8500, 19" monitor. This makes the system almost unusable. Thanks From limbo at bluethingy.com Fri May 7 17:06:09 2004 From: limbo at bluethingy.com (Michael Knepher) Date: Fri, 07 May 2004 10:06:09 -0700 Subject: Core 2 test 3 display problem In-Reply-To: <409BB0E2.80101@telus.net> References: <409BB0E2.80101@telus.net> Message-ID: <1083949569.18669.4.camel@lionel-hutz.darnell.group> On Fri, 2004-05-07 at 09:53 -0600, mace wrote: > Hi, > > I have just installed core2 test 3. The system defaults to 640x480 for > the screen resolution. I have tried changing it, reboot, and it stays > at 640. When I go back into display, it shows the changed in > resolution. Is this a bug or am I doing something wrong. Under > preferences for display it only shows 640x480. > Open /etc/X11/xorg.conf, go to the Monitor section and see if the horizontal and vertical refresh lines are commented out. If the values in the commented lines are correct for your monitor, uncomment them. Then check the Screen section and see if you need to add the resolution settings you want to the Modes lines. > I am running a tyan s2466 motherboard with dual mp2200+ 512 meg ram > 60gig hd, Ati 8500, 19" monitor. > > This makes the system almost unusable. > > Thanks > > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-desktop-list From kblists at comcast.net Fri May 7 23:17:36 2004 From: kblists at comcast.net (Kevin F. Berrien) Date: Fri, 07 May 2004 19:17:36 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <8A44B92A-A01F-11D8-A0B0-000393ADF4E8@sisna.com> References: <20040506160007.1C3CB741A5@hormel.redhat.com> <8A44B92A-A01F-11D8-A0B0-000393ADF4E8@sisna.com> Message-ID: <409C1910.4030504@comcast.net> *Take a screen shot boys and girls! You'll never see anything like this from a non-open source vendor! (I will not speak their names). Thats my pro-linux comment, just had to make it. From: *Will Cohen > ** > I work on performance tools at Red Hat. I have been told there is > interest in tuning the desktop to improve performance. I have a > number > of questions to help identify the work needed in this area. I > would be interested in any answers that people have for the > following questions. > From rada_anr at sancharnet.in Sat May 8 09:10:43 2004 From: rada_anr at sancharnet.in (rada and gus) Date: Sat, 8 May 2004 14:40:43 +0530 Subject: Performance tuning the Fedora Desktop In-Reply-To: <4099587F.4010200@redhat.com> References: <4099587F.4010200@redhat.com> Message-ID: <200405080911.21009.rada_anr@sancharnet.in> Open office takes an inordinately long time to open. The opening speed has not improved significantly as far as I can tell since RH 8 through RH9 and FC-1. Mozilla mail and Evolution take quite a bit longer to open than kmail which is fast, but Mozilla and Evolution have more functionality. I use kdm as the display manager and kde as desktop. I have not tired with gdm or gnome. I did not use any tools to measure the performance, this is just my gestalt impression. Gus On Thursday 06 May 2004 02:41, Will Cohen wrote: > What specific performance problems have people observed so far in the > desktop? For example heavy CPU or memory usage by particular > applications. Another example long latency between event and > resulting action. ... > What metrics were used to gauged the effect of software changes on > performance? ..... From hp at redhat.com Sat May 8 16:11:47 2004 From: hp at redhat.com (Havoc Pennington) Date: Sat, 08 May 2004 12:11:47 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <4099587F.4010200@redhat.com> References: <4099587F.4010200@redhat.com> Message-ID: <1084032706.2944.5.camel@localhost.localdomain> On Wed, 2004-05-05 at 17:11, Will Cohen wrote: > What is the set of software in the "Desktop" (executable names and/or > RPM packages)? The default desktop is GNOME + Mozilla + OpenOffice.org + Evolution. gnome-*, evolution, mozilla, ooffice. Fedora Core also includes KDE (most of /usr/bin/k*), Epiphany, XFCE, and other choices. > What specific performance problems have people observed so far in the > desktop? For example heavy CPU or memory usage by particular > applications. Another example long latency between event and resulting > action. Startup/login times are the most visible latencies, but also repaint (during opaque window resize for example, or opening a menu). > What performance tools have people used so far to identify performance > problems with desktop applications? speedprof, strace -t, memprof, printf-with-clock()/gettimeofday(), Soeren's kernel module. Havoc From wtogami at redhat.com Sun May 9 12:39:37 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 09 May 2004 02:39:37 -1000 Subject: Performance tuning the Fedora Desktop In-Reply-To: <4099587F.4010200@redhat.com> References: <4099587F.4010200@redhat.com> Message-ID: <409E2689.6070307@redhat.com> Will Cohen wrote: > I work on performance tools at Red Hat. I have been told there is > interest in tuning the desktop to improve performance. I have a number > of questions to help identify the work needed in this area. I would be > interested in any answers that people have for the following questions. > On a somewhat related topic of desktop performance, recently fedora.us Extras has begun experimenting with -Os rather than the standard -O2 optimization for our firefox & thunderbird packages. So far it seems to be working very well, with noticably smaller binary RPMS and runtime memory footprint of these two very large applications. I asked gcc developers if they had a guess about which -O2 and -Os would be "faster" for large applications like firefox & thunderbird. They generally replied that they have no idea, because compiler optimization is an inexact science. All kinds of other factors come into play like smaller memory footprint (less swapping), smaller code size (maybe better use of CPU cache). Have there been any past discussions about changing the standard compiler optimization for perhaps FC3? > > What specific performance problems have people observed so far in the > desktop? For example heavy CPU or memory usage by particular > applications. Another example long latency between event and resulting > action. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100423 One long standing desktop bug that has annoyed me personally is Evolution's extreme performance problems when dealing with a large amount of mail in dozens of IMAP folders. It literally takes MINUTES for evolution-1.4.x or evolution-1.5.x to start and read the first message in any IMAP folder due to this problem, while Mozilla, Thunderbird and KMail show new mail almost instantly. (This report also describes an unrelated 100% CPU usage in resizing panes horizontally.) Aside from Evolution, I personally see rpm's huge memory footprint as being a huge problem. Recently I did a full upgrade of FC1 "Everything" to FC2 in a single rpm transaction on a box with 256MB RAM. It took almost 7 hours due to a massive amount of swapping as rpm's memory footprint climbed past 400MB. We really need to improve this situation. I would ask for optimization of rpm's memory footprint to be a high priority for FC3 timeframe, but it may be too scary of a problem. =( On a somewhat related note, the rhn-applet uses more than 30MB of virtual memory. That is just WAY too big. Also look at its CPU time after a few days running. The combined time of it doing *something* seems a bit too much IMHO. Aside from individual applications that need fixing for severe performance problems like the above examples, I see our current desktop software has having poor or lacking behavior in the area of application usage feedback as being a severe usability weakness. Currently we have somewhat acceptable Application Startup Feedback in both GNOME and KDE when programs are launched via panel or menu launchers from .desktop files. The cursor changing to an hour glass or otherwise showing motion and activity when you launch "mozilla" gives the user the feeling that "something is happening" and they must wait. Without application startup feedback, users click on the launcher several more times, and bad things happen. Application Startup Feedback is today not perfect in both GNOME and KDE. It all cases that I am aware of, launching an application from another (i.e. URL handler in gaim) does not trigger the mouse cursor to show activity. This is somewhat related to what I feel is another huge related weakness in our current desktop software: Application Busy Feedback. Within applications, users expect feedback from various operations to indicate that various apps, or parts of apps are busy doing something. Windows seems to have two levels of "busy" feedback. One with the tiny hourglass next to the pointer, and another with the entire cursor turning into an hourglass. I personally see that is quite effective when applications embrace this type of functionality in a fine-grained way. I am not a desktop developer, so I don't know much about the technical guts under the things I described here. Any explanation, links to specifications, and mention of future development related to Application Feedback would be appreciated. Warren Togami wtogami at redhat.com From otaylor at redhat.com Sun May 9 15:56:09 2004 From: otaylor at redhat.com (Owen Taylor) Date: Sun, 09 May 2004 11:56:09 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <409E2689.6070307@redhat.com> References: <4099587F.4010200@redhat.com> <409E2689.6070307@redhat.com> Message-ID: <1084118168.14580.21.camel@localhost.localdomain> On Sun, 2004-05-09 at 08:39, Warren Togami wrote: > Will Cohen wrote: > > I work on performance tools at Red Hat. I have been told there is > > interest in tuning the desktop to improve performance. I have a number > > of questions to help identify the work needed in this area. I would be > > interested in any answers that people have for the following questions. > > > On a somewhat related topic of desktop performance, recently fedora.us > Extras has begun experimenting with -Os rather than the standard -O2 > optimization for our firefox & thunderbird packages. So far it seems to > be working very well, with noticably smaller binary RPMS and runtime > memory footprint of these two very large applications. I asked gcc > developers if they had a guess about which -O2 and -Os would be "faster" > for large applications like firefox & thunderbird. They generally > replied that they have no idea, because compiler optimization is an > inexact science. All kinds of other factors come into play like smaller > memory footprint (less swapping), smaller code size (maybe better use of > CPU cache). > > Have there been any past discussions about changing the standard > compiler optimization for perhaps FC3? Well, I think you've described a wonderful project that someone could do ... recompile the desktop packages with -Os and do some timing. That's the only way we'd know whether we should change the optimization flags or not. Regards, Owen -------------- 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 pbhat at ongc.net Mon May 10 03:07:05 2004 From: pbhat at ongc.net (Parameshwara Bhat) Date: Mon, 10 May 2004 08:37:05 +0530 Subject: System Freezing Completely Message-ID: Hello List, I had very bad freezing of the system,twice today morning - the kind one usually associates only with MS Windows and not Linux - quite unexpectedly. I was running Opera Browser-7.23 version and wget-1.8.2-15.3 at the time.I have used Opera earlier and not seen this kind of problem.This problem repeated when wget was running alone too. Only change in my system since installation was new modemboard based on smartlink chipset and driver slmdm-version 2.7.14. I could not change over to either commandline-mode (ctrl+alt+F1) or invoke sysguard program to kill anyof these applications.Keyboard and mouse were dead too. I didnot anything else to do.What else is there to do in such a situation? Has anybody had this kind of problem in Fedora or Linux in general ? Parameshwara Bhat -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From wtogami at redhat.com Mon May 10 06:32:37 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 09 May 2004 20:32:37 -1000 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1084118168.14580.21.camel@localhost.localdomain> References: <4099587F.4010200@redhat.com> <409E2689.6070307@redhat.com> <1084118168.14580.21.camel@localhost.localdomain> Message-ID: <409F2205.6060505@redhat.com> Owen Taylor wrote: >>On a somewhat related topic of desktop performance, recently fedora.us >>Extras has begun experimenting with -Os rather than the standard -O2 >>optimization for our firefox & thunderbird packages. So far it seems to >>be working very well, with noticably smaller binary RPMS and runtime >>memory footprint of these two very large applications. I asked gcc >>developers if they had a guess about which -O2 and -Os would be "faster" >>for large applications like firefox & thunderbird. They generally >>replied that they have no idea, because compiler optimization is an >>inexact science. All kinds of other factors come into play like smaller >>memory footprint (less swapping), smaller code size (maybe better use of >>CPU cache). >> >>Have there been any past discussions about changing the standard >>compiler optimization for perhaps FC3? > > > Well, I think you've described a wonderful project that someone could do > ... recompile the desktop packages with -Os and do some timing. That's > the only way we'd know whether we should change the optimization flags > or not. > > Regards, > Owen > > I just noticed today that the recent FC2 kernels are built with -Os rather than -O2. Just another data point for now. Warren From sandmann at redhat.com Mon May 10 09:51:24 2004 From: sandmann at redhat.com (Soeren Sandmann Pedersen) Date: Mon, 10 May 2004 11:51:24 +0200 Subject: Performance tuning the Fedora Desktop In-Reply-To: <4099587F.4010200@redhat.com> References: <4099587F.4010200@redhat.com> Message-ID: <1084182683.5315.111.camel@localhost.localdomain> Hi Will > How well or poorly did the performance tools work in identifying the > performance problem? I think profiling CPU usage at the desktop level has two important properties: 1 A call graph is essential 2 The data don't have to be very accurate Ad 1: The desktop CPU problems are generally algorithmic in nature. The big improvements come from fixing O(n^2) algorithms and from adding caching and other high-level optimizations. To do this it is essential to know *why* something time-consuming is being done, so that you can in the best case change the algorithm to not actually do it anymore. Ad 2: Since you are working on high-level optimizations, you need to know stuff like "30% in metacity" and get a rough break-down of those 30%. The profiler must not be so intrusive that the applications become unusable, but slightly skewed data is not a disaster. This high-level optimization is in contrast to tuning of inner loops, where the properties are reversed: 1 In which function do we spend the time 2 What, exactly, is the CPU doing. You want to know about cache misses and divisions and branch predictions and such things. You want to know in what lines of source code the time is spent. In this case you generally don't try to stop doing it, you try to do it faster. The sysprof profiler, which can be checked out of GNOME cvs, is clearly aiming at the first kind of profiling. Sysprof works with a kernel module that 50 times per second generates a stacktrace of the process in the "current" variable, unless the pid of that process is 0. A userspace application then reads those stacktraces and presents the information graphically in lists and trees. So it is a statistical, sampling profiler. The kernel code probably reveals that I am not an experienced kernel hacker. Generally I worked from various driver writing guides I found on the net, and I consider it quite likely to break on more exotic kernels, where "exotic" means different from mine. Its killer feature I think is the presentation of the data. For each function you can get a complete break-down of the children in which that function spends its time. This even works with recursion, including mutual recursion. Generally it never reports a function as calling itself, instead it combines the numbers correctly. The not completely trivial details would make this mail much longer. That you can change the view of the data quickly makes it possible to get a good high-level overview of the performance characteristics of the system. A different property sysprof has is that it is fairly easy to get running. Just install a kernel module and start the application and you are set. I found oprofile a bit more difficult to get started with. It seems to me that since oprofile probably reports more and better data than my kernel module, we should try and get the graphical presentation from sysprof to present oprofile data. It shouldn't be too difficult to do this; the presentation code was lifted from the memprof/speedprof profiler and is quite independent of the rest of the profiler. (Actually you could argue that the presentation code pretty much _is_ the entire profiler). Another thing that might be nice is a library that would allow symbol lookup in binaries. I spent quite a bit of time whacking the memprof code to deal with prelinked binaries, and I am not too confident I got it completely right. Soeren From wcohen at redhat.com Mon May 10 16:12:25 2004 From: wcohen at redhat.com (Will Cohen) Date: Mon, 10 May 2004 12:12:25 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1084182683.5315.111.camel@localhost.localdomain> References: <4099587F.4010200@redhat.com> <1084182683.5315.111.camel@localhost.localdomain> Message-ID: <409FA9E9.2030405@redhat.com> Soeren Sandmann Pedersen wrote: > Hi Will > > >>How well or poorly did the performance tools work in identifying the >>performance problem? > > > I think profiling CPU usage at the desktop level has two important > properties: > > 1 A call graph is essential > 2 The data don't have to be very accurate > > Ad 1: The desktop CPU problems are generally algorithmic in nature. The > big improvements come from fixing O(n^2) algorithms and from adding > caching and other high-level optimizations. To do this it is essential > to know *why* something time-consuming is being done, so that you can in > the best case change the algorithm to not actually do it anymore. The algorithms selected have a huge impact on performance. However, it is not always clear that the algorithm selected is wrong until the code is used. Data structures have different strengths, e.g. cheap to index and fetch from an array, but it expensive to insert elements into beginning of array. > Ad 2: Since you are working on high-level optimizations, you need to > know stuff like "30% in metacity" and get a rough break-down of those > 30%. The profiler must not be so intrusive that the applications become > unusable, but slightly skewed data is not a disaster. Yes, low overhead is more important than absolute accuracy. I think for right now the tuning is looking for the "low hanging fruit". Whether the profiler says that something take 30% or 33% is not going to make a big difference. For the most part just want to point out the major resource hogs. It would painful for users of the GUI on the desktop to be slowed by emulation, plus users might do things different if the speed is too different. > This high-level optimization is in contrast to tuning of inner loops, > where the properties are reversed: > > 1 In which function do we spend the time > 2 What, exactly, is the CPU doing. You want to know about > cache misses and divisions and branch predictions and such > things. You want to know in what lines of source code the time > is spent. > > In this case you generally don't try to stop doing it, you try to do it > faster. OProfile can certainly provide information on cache misses, branch predictions, and other performance monitoring events. > The sysprof profiler, which can be checked out of GNOME cvs, is clearly > aiming at the first kind of profiling. > > Sysprof works with a kernel module that 50 times per second generates a > stacktrace of the process in the "current" variable, unless the pid of > that process is 0. A userspace application then reads those stacktraces > and presents the information graphically in lists and trees. The oprofile support in Fedora Core 2 test3 has a similar mechanism to walk to the stack, but it typically uses the performance monitoring hardware to trigger the sampling. It only works for x86 (other processors do not include frame pointers). You might want to take a look at it. It won't work for hugemem kernels because there are separate address spaces for user and kernel mode, but I imagine for most desktop work people are not using hugemem kernels. On Pentium4 and Pentium M there are performance monitoring events that count calls, so the sampling can be done based on the number of calls. This may be more desirable than a time-based samples. However, one drawback of this statistical call grap information is one ends up with a call graph forest rather than a call graph tree. The sampling will miss the lone call that causes a lot of work unless the code happens to walk far enough up the stack. Does the sysprof stack tracer you use walked the entire user stack each time it takes a sample? > So it is a statistical, sampling profiler. The kernel code probably > reveals that I am not an experienced kernel hacker. Generally I worked > from various driver writing guides I found on the net, and I consider it > quite likely to break on more exotic kernels, where "exotic" means > different from mine. > > Its killer feature I think is the presentation of the data. For each > function you can get a complete break-down of the children in which that > function spends its time. This even works with recursion, including > mutual recursion. Generally it never reports a function as calling > itself, instead it combines the numbers correctly. The not completely > trivial details would make this mail much longer. > > That you can change the view of the data quickly makes it possible to > get a good high-level overview of the performance characteristics of the > system. > > A different property sysprof has is that it is fairly easy to get > running. Just install a kernel module and start the application and you > are set. I found oprofile a bit more difficult to get started with. oprofile has been more difficult to set up in the past. However, pretty much one can just install an RH smp kernel, boot the RH smp kernel, "opcontrol --setup --no-vmlinux; opcontrol --start", and one has profiling for user code. There is still room for improvement. > It seems to me that since oprofile probably reports more and better data > than my kernel module, we should try and get the graphical presentation > from sysprof to present oprofile data. It shouldn't be too difficult to > do this; the presentation code was lifted from the memprof/speedprof > profiler and is quite independent of the rest of the profiler. (Actually > you could argue that the presentation code pretty much _is_ the entire > profiler). I will take a look at the sysprof to see how it presents data. > Another thing that might be nice is a library that would allow symbol > lookup in binaries. I spent quite a bit of time whacking the memprof > code to deal with prelinked binaries, and I am not too confident I got > it completely right. > > > Soeren Thanks for the comments. -Will From blocke at shivan.org Mon May 10 22:29:18 2004 From: blocke at shivan.org (Bruce A. Locke) Date: Mon, 10 May 2004 18:29:18 -0400 Subject: Bluecurve Sound Theme? Message-ID: <1084228158.2362.3.camel@kodiak.shivan.org> Has any thought been put into a Bluecurve sound theme for the GNOME and KDE desktop environments over in the new Red Hat Desktop office? Just curious. :) -- ------------------------------------------------------------------ Bruce A. Locke blocke at shivan.org From warrwalker at hotmail.com Tue May 11 00:45:43 2004 From: warrwalker at hotmail.com (Warren Walker) Date: Mon, 10 May 2004 20:45:43 -0400 Subject: LTWinmodem Message-ID: I recently successfully installed Fedora on an old IBM Aptiva [Amd k6-2 366, 64 Mb Ram, 3.1Gb HD]. What can I do to get Fedora to recognize the LTWinmodem? Can Fedora recognize a Speedstream 5200 USB DSL modem? Warren____________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Tue May 11 08:12:27 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 10 May 2004 22:12:27 -1000 Subject: Help Needed: Firefox 0.8 and Thunderbird 0.6 Message-ID: <40A08AEB.1030705@redhat.com> https://bugzilla.fedora.us/show_bug.cgi?id=1460 Please assist Fedora Extras in preparing revisions of the firefox-0.8 and thunderbird-0.6 packages before the release of FC2. These packages are patched with Blizzard's xremote fixes which finally allow perfect integration with both firefox & thunderbird running simultaneously. We have also spent a great deal of time making sure they work within the newly fixed Preferred Application framework of FC2. Only minor changes are needed to both packages before publication. Also it would help if Fedora Desktop volunteers can help to contact upstream developers to either act as liasons, or work directly with Fedora Extras development. https://bugzilla.fedora.us/show_bug.cgi?id=1443 Even non-programmers can help by searching upstream mozilla.org bugzilla and talking to firefox or mozilla developers about this issue. It is very likely that there already exists a patch or workaround for this issue, but the developers are too busy to search for it. You can help! For example, we have made this kind of very successful partnership with three upstream gaim developers. They are automatically added to all Fedora gaim bug reports, and have helped us immensely to be very responsive to user bugzilla reports and package fixing. (Currently there are ZERO open gaim reports in FC!) Warren Togami wtogami at redhat.com From alexl at redhat.com Tue May 11 12:30:44 2004 From: alexl at redhat.com (Alexander Larsson) Date: 11 May 2004 14:30:44 +0200 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1083942511.3362.5.camel@julien> References: <4099587F.4010200@redhat.com> <1083942511.3362.5.camel@julien> Message-ID: <1084278644.19104.60.camel@localhost.localdomain> On Fri, 2004-05-07 at 17:08, Julien Olivier wrote: > On Wed, 2004-05-05 at 22:11, Will Cohen wrote: > And, from time to time, clicking on the main menu takes ages to display > the menu (where ages really mean up to 10 seconds) I think the panel loads the menu "on-demand" to save memory, and once its loaded its forgotten if not used for a while. Or something like that. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a benighted soccer-playing jungle king with no name. She's a time-travelling renegade widow with an evil twin sister. They fight crime! From alexl at redhat.com Tue May 11 13:31:47 2004 From: alexl at redhat.com (Alexander Larsson) Date: 11 May 2004 15:31:47 +0200 Subject: Performance tuning the Fedora Desktop In-Reply-To: <4099587F.4010200@redhat.com> References: <4099587F.4010200@redhat.com> Message-ID: <1084282307.19104.117.camel@localhost.localdomain> On Wed, 2004-05-05 at 23:11, Will Cohen wrote: > I work on performance tools at Red Hat. I have been told there is > interest in tuning the desktop to improve performance. I have a number > of questions to help identify the work needed in this area. I would be > interested in any answers that people have for the following questions. > > > What is the set of software in the "Desktop" (executable names and/or > RPM packages)? For the last few years I've been working on and off on the performance of Nautilus. At this time Nautilus is a lot better performance-wise, but we still don't fully grasp the performance properties of it. I'll try to give you some idea of what i've been doing. > What specific performance problems have people observed so far in the > desktop? For example heavy CPU or memory usage by particular > applications. Another example long latency between event and resulting > action. Nautilus has had various problems. One important one is the time it takes to open a new window, other ones are startup time, time to read a large directory, and total memory use. > What metrics were used to gauged the effect of software changes on > performance? In general, the slowness have been on a scale that you could use a handwatch to time it (for e.g. directory load), and at other times I've put in printfs() to print time() at some specific points in the app. Often you can see the performance increase by just using the app. > What performance tools have people used so far to identify performance > problems with desktop applications? I use a variety of tools: * printfs in strategic places to try to figure out what gets called, when it gets called, and how long it takes. * Sprinkle "access ("doing ", 0) in the code, then run the app under strace -tt, which will show you what sort of i/o is done. You can look at the access lines in the log to see what is happening at the code level, including timestamps. * I've used the sampling profiler in eazel-tools in gnome cvs. This is a sampling profiler that you LD_PRELOAD into your app. Its not perfect, but it gives you at least some data when used with shared libs (as opposed to gprof). It gives gprof output. * KCachegrind. I've only used this a bit, the performance of Nautilus while running it is pretty poor, so its hard to use. * memprof. This is an excellent app for tracking down leaks and large users of memory. > How well or poorly did the performance tools work in identifying the > performance problem? While they did help, they are not as useful as I would like. They require a lot of work to set up, and the presentation/data-mining features are pretty limited. In general, debugging desktop apps is quite different from lowlevel, non-interactive apps. First of all they are generally much more structurally complex, relying on many shared libraries, several processes with various sorts of IPC and lots of file I/O and user input. Secondly, the typical call traces are very deep (60 or even 80 frames are not uncommon), and often highly recursive. A typical backtrace involves several signal emissions, where each emission is on the order of 5 function calls deep (just for the signal emission code, not the called function). These functions are also typically the same, so they intermingle the stack traces. Take this simplified backtrace for instance: A: signal_a_handler () - foo(); return TRUE; g_signal_emit () - locate callback, call caller_a() - g_signal_emit (object, "signal_a", data) B: signal_b_handler () - bar(); return TRUE; g_signal_emit () - locate callback, call caller_b() - g_signal_emit (object, "signal_b", data) When looking at a profile for code such as this, what you see is that caller_a() uses a lot of time, but when you go into it to see what it does, you end up looking at g_signal_emit, which gets called by lots of other places like B, so its very hard to figure out what of that is actually from the A call. It gets even worse in the (very common) situation of the signal handler itself emitting a signal. This creates a mutual recursion into the g_signal_emit() function similar to the a+b case above: signal_b_handler() g_signal_emit ("signal b") signal_a_handler () g_signal_emit ("signal a") caller_a() When stepping into the g_signal_emit from signal_a_handler it seems like that calls signal_a_handler again, since thats another child of g_signal_emit. Profilers just don't handle this very well. Here is a couple of issues I have with current profiling tools: * They have no way of profiling i/o and seeks. A lot of our problems is due to reading to many files, reading files to often, or paging in data/code. Current profilers just don't show this at all. * Little support for tracking issues wrt IPC calls between different processes. Whether this be X inter-client calls for e.g. DnD, or Corba calls to some object. * Poor visialization support of the data, especially with mutually recursive calls as described above. Generally, all of the fixes I've done has been of the type "Don't do this incredibly stupid thing". Whether that has been O(n^2) algorithm due to treating a list as an arrays in loops, reading the same file over and over again, or something else. I've never *once* had to count cycles in some hot function or anything like that, Its always about adding a cache, doing something in a different way, or just avoid doing the expensive stupid thing. However, the stupidities are burried in lots and lots of code, and finding them in all the data a profiler spews out is the real hard part. > Were benchmarks used to test performance of desktop applications? If > so, what type of benchmarks were used (e.g. micro benchmarks or > measuring the amount of time required to do something in an > application program)? Typically not. They were all ad-hoc testing by the developer as part of trying to track down some specific slowness. > Were the benchmarks runnable in batch mode without human assistance? Never. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a superhumanly strong flyboy senator on the wrong side of the law. She's a time-travelling motormouth detective with only herself to blame. They fight crime! From alexl at redhat.com Tue May 11 13:34:41 2004 From: alexl at redhat.com (Alexander Larsson) Date: 11 May 2004 15:34:41 +0200 Subject: Performance tuning the Fedora Desktop In-Reply-To: <409C1910.4030504@comcast.net> References: <20040506160007.1C3CB741A5@hormel.redhat.com> <8A44B92A-A01F-11D8-A0B0-000393ADF4E8@sisna.com> <409C1910.4030504@comcast.net> Message-ID: <1084282481.19104.121.camel@localhost.localdomain> On Sat, 2004-05-08 at 01:17, Kevin F. Berrien wrote: > *Take a screen shot boys and girls! You'll never see anything like this > from a non-open source vendor! (I will not speak their names). You don't think that Microsoft does performance work? They most certainly do. And they're pretty good at it too. Of course, if they get input from people for performance work its all private, under NDAs and stuff like that. This is where we can do better. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a maverick white trash Green Beret living undercover at Ringling Bros. Circus. She's a psychotic mutant stripper married to the Mob. They fight crime! From markmc at redhat.com Tue May 11 12:30:19 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 11 May 2004 13:30:19 +0100 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1084278644.19104.60.camel@localhost.localdomain> References: <4099587F.4010200@redhat.com> <1083942511.3362.5.camel@julien> <1084278644.19104.60.camel@localhost.localdomain> Message-ID: <1084278618.3234.11.camel@laptop> Hi, On Tue, 2004-05-11 at 13:30, Alexander Larsson wrote: > On Fri, 2004-05-07 at 17:08, Julien Olivier wrote: > > On Wed, 2004-05-05 at 22:11, Will Cohen wrote: > > And, from time to time, clicking on the main menu takes ages to display > > the menu (where ages really mean up to 10 seconds) > > I think the panel loads the menu "on-demand" to save memory, and once > its loaded its forgotten if not used for a while. Or something like > that. I haven't quite figured out whats going on here yet. There are a number of options: 1) We check and re-read the menu on click 2) The menu has been swapped out by that stage 3) Destroying the GTK+ menu takes a long time (this was a problem at one point with GTK+ 2.3.x, but that got fixed) It needs profiling. Cheers, Mark. From dcbw at redhat.com Tue May 11 14:26:55 2004 From: dcbw at redhat.com (Dan Williams) Date: Tue, 11 May 2004 10:26:55 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1084278618.3234.11.camel@laptop> References: <4099587F.4010200@redhat.com> <1083942511.3362.5.camel@julien> <1084278644.19104.60.camel@localhost.localdomain> <1084278618.3234.11.camel@laptop> Message-ID: <1084285615.3500.3.camel@dcbw.boston.redhat.com> Hi, The Menu VFS code has to do a number of things when the panel first reads it as well: 1) Locate and read all .menu files in /etc/xdg/menus 2) Parse these menus and locate all .desktop/.directory directories 3) Parse all .desktop/.directory files from (2) to find out their categories, names, and OnlyShowIn values 4) Create the actual menu structure from the data in (2) and (3) There is definitely room for improvement and optimization here in the menu code, but 1 - 4 have to happen in any case, which includes a lot of hitting the disk. So if you're doing something disk intensive at the time you first click, it might take a couple seconds. Also, if the directories or files in (1) and (2) get touched or changed, the whole menu structure is currently rebuilt to make it aware of changes, which means invalidating a lot of cache and reloading many bits of info. Dan On Tue, 2004-05-11 at 13:30 +0100, Mark McLoughlin wrote: > Hi, > > On Tue, 2004-05-11 at 13:30, Alexander Larsson wrote: > > On Fri, 2004-05-07 at 17:08, Julien Olivier wrote: > > > On Wed, 2004-05-05 at 22:11, Will Cohen wrote: > > > And, from time to time, clicking on the main menu takes ages to display > > > the menu (where ages really mean up to 10 seconds) > > > > I think the panel loads the menu "on-demand" to save memory, and once > > its loaded its forgotten if not used for a while. Or something like > > that. > > I haven't quite figured out whats going on here yet. There are a number > of options: > > 1) We check and re-read the menu on click > > 2) The menu has been swapped out by that stage > > 3) Destroying the GTK+ menu takes a long time (this was a problem at > one point with GTK+ 2.3.x, but that got fixed) > > It needs profiling. > > Cheers, > Mark. > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-desktop-list From veillard at redhat.com Tue May 11 14:40:30 2004 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 11 May 2004 10:40:30 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1084032706.2944.5.camel@localhost.localdomain> References: <4099587F.4010200@redhat.com> <1084032706.2944.5.camel@localhost.localdomain> Message-ID: <20040511144028.GB21615@redhat.com> On Sat, May 08, 2004 at 12:11:47PM -0400, Havoc Pennington wrote: > > What performance tools have people used so far to identify performance > > problems with desktop applications? > > speedprof, strace -t, memprof, printf-with-clock()/gettimeofday(), > Soeren's kernel module. What I'm somewhat still missing is code coverage analysis, this would be useful for regression tests analysis but also to try to isolate code that is never run in "normal" scenarios. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From wcohen at redhat.com Tue May 11 20:08:21 2004 From: wcohen at redhat.com (Will Cohen) Date: Tue, 11 May 2004 16:08:21 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <409E2689.6070307@redhat.com> References: <4099587F.4010200@redhat.com> <409E2689.6070307@redhat.com> Message-ID: <40A132B5.3030200@redhat.com> Warren Togami wrote: > Will Cohen wrote: > >> I work on performance tools at Red Hat. I have been told there is >> interest in tuning the desktop to improve performance. I have a number >> of questions to help identify the work needed in this area. I would be >> interested in any answers that people have for the following questions. >> > > On a somewhat related topic of desktop performance, recently fedora.us > Extras has begun experimenting with -Os rather than the standard -O2 > optimization for our firefox & thunderbird packages. So far it seems to > be working very well, with noticably smaller binary RPMS and runtime > memory footprint of these two very large applications. I asked gcc > developers if they had a guess about which -O2 and -Os would be "faster" > for large applications like firefox & thunderbird. They generally > replied that they have no idea, because compiler optimization is an > inexact science. All kinds of other factors come into play like smaller > memory footprint (less swapping), smaller code size (maybe better use of > CPU cache). It is quite possible that the saving in space could give significant performance benefits. Code fitting better in instruction cache, fewer page misses, and paging could be a large win than getting some inner loop to run faster. > Have there been any past discussions about changing the standard > compiler optimization for perhaps FC3? I have seen some discussions on -Os vs -O2, but I haven't seen actual performance comparisons. >> What specific performance problems have people observed so far in the >> desktop? For example heavy CPU or memory usage by particular >> applications. Another example long latency between event and resulting >> action. > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100423 > One long standing desktop bug that has annoyed me personally is > Evolution's extreme performance problems when dealing with a large > amount of mail in dozens of IMAP folders. It literally takes MINUTES > for evolution-1.4.x or evolution-1.5.x to start and read the first > message in any IMAP folder due to this problem, while Mozilla, > Thunderbird and KMail show new mail almost instantly. > (This report also describes an unrelated 100% CPU usage in resizing > panes horizontally.) > > Aside from Evolution, I personally see rpm's huge memory footprint as > being a huge problem. Recently I did a full upgrade of FC1 "Everything" > to FC2 in a single rpm transaction on a box with 256MB RAM. It took > almost 7 hours due to a massive amount of swapping as rpm's memory > footprint climbed past 400MB. We really need to improve this situation. > I would ask for optimization of rpm's memory footprint to be a high > priority for FC3 timeframe, but it may be too scary of a problem. =( Jeff Johnson has mentioned the performance problems with the rpm internals to me before. > On a somewhat related note, the rhn-applet uses more than 30MB of > virtual memory. That is just WAY too big. Also look at its CPU time > after a few days running. The combined time of it doing *something* > seems a bit too much IMHO. 30 MB? Do you have anymore details on that, e.g. space for code and data? Where there just a huge number of libraries being pulled in? > Aside from individual applications that need fixing for severe > performance problems like the above examples, I see our current desktop > software has having poor or lacking behavior in the area of application > usage feedback as being a severe usability weakness. > > Currently we have somewhat acceptable Application Startup Feedback in > both GNOME and KDE when programs are launched via panel or menu > launchers from .desktop files. The cursor changing to an hour glass or > otherwise showing motion and activity when you launch "mozilla" gives > the user the feeling that "something is happening" and they must wait. > Without application startup feedback, users click on the launcher > several more times, and bad things happen. > > Application Startup Feedback is today not perfect in both GNOME and KDE. > It all cases that I am aware of, launching an application from another > (i.e. URL handler in gaim) does not trigger the mouse cursor to show > activity. > > This is somewhat related to what I feel is another huge related weakness > in our current desktop software: Application Busy Feedback. Within > applications, users expect feedback from various operations to indicate > that various apps, or parts of apps are busy doing something. Windows > seems to have two levels of "busy" feedback. One with the tiny > hourglass next to the pointer, and another with the entire cursor > turning into an hourglass. I personally see that is quite effective > when applications embrace this type of functionality in a fine-grained way. > > I am not a desktop developer, so I don't know much about the technical > guts under the things I described here. Any explanation, links to > specifications, and mention of future development related to Application > Feedback would be appreciated. Response time for actions has come up in a number of the responses to my mail. If the response was very fast, then the feedback wouldn't be an issue. However, given the response times, it appears that the system isn't reacting to the input. Some developers have used strategic printf and accesses to get data out like how long it took to get from here to there. Another thing we might consider is the ability to start and stop oprofile sampling at particular places in code. For example, instrument the code to start oprofile sampling on a particular action and then stop oprofile sampling on another event. This would avoid interesting data getting buried in the long term data. Using oprofile in this manner would give a better picture of what sections of code are getting exercised for certain actions. -Will From veillard at redhat.com Tue May 11 20:44:59 2004 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 11 May 2004 16:44:59 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <40A132B5.3030200@redhat.com> References: <4099587F.4010200@redhat.com> <409E2689.6070307@redhat.com> <40A132B5.3030200@redhat.com> Message-ID: <20040511204459.GI29881@redhat.com> On Tue, May 11, 2004 at 04:08:21PM -0400, Will Cohen wrote: > >On a somewhat related note, the rhn-applet uses more than 30MB of > >virtual memory. That is just WAY too big. Also look at its CPU time > >after a few days running. The combined time of it doing *something* > >seems a bit too much IMHO. > > 30 MB? Do you have anymore details on that, e.g. space for code and > data? Where there just a huge number of libraries being pulled in? Well, first there is Python plus all the bindings for GTK/Glade/Gnome/panel http/https/yum/apt/xml-rpc modules. There is also an internal set of current header informations from the RPM database to avoid seeking the rpmdb constantly. The CPU time can grow very fast if the applet is in blinking/fade mode (my request for dropping this feature was refused) there is also a non neglectible startup CPU consumption setting up the environment and scanning the installed rpm database for the current state. Anyway from a purely desktop POV, I think the applet must go, the machine should be up2date and if not the report should go to the sysadmin, not to the user. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From hp at redhat.com Wed May 12 02:29:27 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 11 May 2004 22:29:27 -0400 Subject: window managers Message-ID: <1084328966.2569.15.camel@localhost.localdomain> Hi, I'm triaging my bugs and there are a few sawfish issues that I know I won't get around to fixing. Also at this point I think most people wanting a more featureful WM are using a more maintained one, there's a list of EWMH compliant WMs at http://freedesktop.org/standards/wm-spec Even of those included with FC2, there's a good chance KWin and xfwm both work OK with GNOME. So suggestions: 1) if we have a random more-features WM in Core, I think it should probably be one of the more maintained ones instead of Sawfish 2) maybe the right path instead is to put extra WMs in Extras and only the full desktop envs - gnome, kde, xfce, and classic (twm/xterm) - in Core 3) either way, pretty sure someone other than me should be maintaining the package Havoc From sandmann at redhat.com Wed May 12 09:50:36 2004 From: sandmann at redhat.com (Soeren Sandmann Pedersen) Date: Wed, 12 May 2004 11:50:36 +0200 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1084282307.19104.117.camel@localhost.localdomain> References: <4099587F.4010200@redhat.com> <1084282307.19104.117.camel@localhost.localdomain> Message-ID: <1084355436.5733.33.camel@localhost.localdomain> On Tue, 2004-05-11 at 15:31, Alexander Larsson wrote: > In general, debugging desktop apps is quite different from lowlevel, > non-interactive apps. First of all they are generally much more > structurally complex, relying on many shared libraries, several > processes with various sorts of IPC and lots of file I/O and user input. > Secondly, the typical call traces are very deep (60 or even 80 frames > are not uncommon), and often highly recursive. A typical backtrace > involves several signal emissions, where each emission is on the order > of 5 function calls deep (just for the signal emission code, not the > called function). These functions are also typically the same, so they > intermingle the stack traces. Take this simplified backtrace for > instance: > > A: > signal_a_handler () - foo(); return TRUE; > g_signal_emit () - locate callback, call > caller_a() - g_signal_emit (object, "signal_a", data) > > B: > signal_b_handler () - bar(); return TRUE; > g_signal_emit () - locate callback, call > caller_b() - g_signal_emit (object, "signal_b", data) > > When looking at a profile for code such as this, what you see is that > caller_a() uses a lot of time, but when you go into it to see what it > does, you end up looking at g_signal_emit, which gets called by lots of > other places like B, so its very hard to figure out what of that is > actually from the A call. > > It gets even worse in the (very common) situation of the signal handler > itself emitting a signal. This creates a mutual recursion into the > g_signal_emit() function similar to the a+b case above: > > signal_b_handler() > g_signal_emit ("signal b") > signal_a_handler () > g_signal_emit ("signal a") > caller_a() > > When stepping into the g_signal_emit from signal_a_handler it seems like > that calls signal_a_handler again, since thats another child of > g_signal_emit. Profilers just don't handle this very well. If you haven't already, I'd suggest looking at either the speedprof profiler that comes with memprof (you'll have to use cvs HEAD) or the sysprof profiler. They both have a visualization that helps with this problem a lot. For example the stack trace above: signal_b_handler() g_signal_emit ("signal b") signal_a_handler () g_signal_emit ("signal a") caller_a() will be visualized as this tree: Self Total caller_a() 0% 100% g_signal_emit () 0% 100% signal_a_handler() 0% 100% signal_b_handler() 100% 100% So all the recursions through g_signal_emit() are combined and shown in one list. In other words you get a break-down even for recursive data. If either of the signal handlers were to emit another signal, the visualization would be the same, except that the numbers would be different. > Here is a couple of issues I have with current profiling tools: > * They have no way of profiling i/o and seeks. A lot of our problems is > due to reading to many files, reading files to often, or paging in > data/code. Current profilers just don't show this at all. I agree. What would be really nice is we could get the kernel for each disk access to provide this information: - what process caused it to happen - what is the stack trace of the process when it happened - what kind of disk access - page fault: what address faulted - read: what file was read - other kinds of disk access With that information it would be possible to see what parts of an application are responsible for disk access. Also minor page faults would be interesting to know about for startup time, because they represent the worst case page fault-wise (they *could* have been major faults if a different set of pages were in memory). S?ren From sandmann at redhat.com Wed May 12 09:59:27 2004 From: sandmann at redhat.com (Soeren Sandmann Pedersen) Date: Wed, 12 May 2004 11:59:27 +0200 Subject: Performance tuning the Fedora Desktop In-Reply-To: <409FA9E9.2030405@redhat.com> References: <4099587F.4010200@redhat.com> <1084182683.5315.111.camel@localhost.localdomain> <409FA9E9.2030405@redhat.com> Message-ID: <1084355967.5733.42.camel@localhost.localdomain> On Mon, 2004-05-10 at 18:12, Will Cohen wrote: > However, one drawback of this statistical call grap information is one > ends up with a call graph forest rather than a call graph tree. The > sampling will miss the lone call that causes a lot of work unless the > code happens to walk far enough up the stack. Does the sysprof stack > tracer you use walked the entire user stack each time it takes a sample? It traces up to 256 addresses, which is normally enough room for the entire stack. Usually sysprof reports something like 96% time spent in _libc_start_main(). I assume the remaining 4% is accounting for applications that have either a very deep stack (> 256) causing another function to appear as the first call, or are just weird in other ways. S?ren From foolish at guezz.net Wed May 12 18:21:12 2004 From: foolish at guezz.net (Sindre Pedersen Bjordal) Date: Wed, 12 May 2004 20:21:12 +0200 Subject: Fedora cd artwork: Covers, CD-labels etc. Message-ID: <1084386072.4782.6.camel@localhost.localdomain> I was wondering, do any of you know of any Fedora artwork that can be made into a cover and CD-label for my Fedora CD-set or maybe even some finished covers or cd-labels? If someone not as artistically retarded as me decided to make something like this, will it be ok (as in legal) to distribute it? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From mandreiana at rdslink.ro Wed May 12 07:00:07 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Wed, 12 May 2004 10:00:07 +0300 Subject: Performance tuning the Fedora Desktop In-Reply-To: <4099587F.4010200@redhat.com> References: <4099587F.4010200@redhat.com> Message-ID: <1084345202.5085.5.camel@marte.biciclete.ro> On Thu, 2004-05-06 at 00:11, Will Cohen wrote: > What specific performance problems have people observed so far in the > desktop? when HDD is used by an application (copying a large file, updatedb...), all the applications respond slow. The preemptible kernel patch should solve this, but it's not enabled in FC2. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From wcohen at redhat.com Wed May 12 21:26:02 2004 From: wcohen at redhat.com (Will Cohen) Date: Wed, 12 May 2004 17:26:02 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1084345202.5085.5.camel@marte.biciclete.ro> References: <4099587F.4010200@redhat.com> <1084345202.5085.5.camel@marte.biciclete.ro> Message-ID: <40A2966A.8070209@redhat.com> Marius Andreiana wrote: > On Thu, 2004-05-06 at 00:11, Will Cohen wrote: > >>What specific performance problems have people observed so far in the >>desktop? > > when HDD is used by an application (copying a large file, updatedb...), > all the applications respond slow. The preemptible kernel patch should > solve this, but it's not enabled in FC2. Are you sure that the preemptible kernel fixes this problem. I thought this was related to application code getting swapped out to make more room for disk cache. http://www.spinics.net/lists/kernel/msg262920.html Anyway the slow response does make the desktop less pleasant to use. -Will From jorris at redhat.com Wed May 12 21:34:54 2004 From: jorris at redhat.com (Jon Orris) Date: Wed, 12 May 2004 17:34:54 -0400 Subject: Shared Calendars Message-ID: <40A2987E.7080600@redhat.com> After reading http://www.redhat.com/archives/fedora-desktop-list/2004-April/msg00035.html I've been taking a look at groupware/calendaring solutions, and wanted to share my thoughts on it: System requirements: Performance & scalability: The system should scale to hundreds, and ideally thousands of users. It should be easy to purchase better hardware or add servers in a clustered environment to improve performance and support large numbers of users. Community: Ideally, the project should already have a strong Open Source community around it. Standards: The product needs to support common open components and standards. The use of standard protocols for storage & exchange of data is important. There are some projects that use standard components, but in very unusual ways with no standard protocol for exchange. Some relevant standards are: (The below lists of standards & features, excepting Evolution integration, are from http://www.redhat.com/archives/fedora-desktop-list/2004-April/msg00058.html) http://www.imc.org/ietf-calendar/index.htmliCalendar/iCal (RFC2445) http://www.ietf.org/rfc/rfc2445.txtxCal (iCalendar DTD document) http://xml.coverpages.org/iCal.htmlCalendar Server Extensions for WebDAV (CalDAV) http://greenbytes.de/tech/webdav/draft-dusseault-caldav-00.htmliTIP (RFC 2446) Transport-independent Interoperability protocol http://www.ietf.org/rfc/rfc2446.txtiMIP (RFC 2447) Message-based Interoperability Protocol http://www.ietf.org/rfc/rfc2447.txtCalendar Access Protocol (CAP) transport over BEEP http://www.beepcore.org/beepcore/home.jsp http://beepcore.org/beepcore/docs/profile-cap.htmlICAP (extension of IMAP 4 to support CAP) http://www.wirs.aber.ac.uk/spk/Diary/icap-draft.htm#Overview Features: * Single-Sign On (usually via Directory integration) * user management via "address book users" rather than "system users" * Group scheduling/Meeting creation * Resource scheduling (ie. room availability, notebook checkout...) * Free/busy time * Merging of multiple calendars * import/export iCal * synchronization: * to handhelds/phone * to notebook * to other calendar servers * notification/reminder mechanism * Evolution Integration Anyone have other requirements we haven't thought of here? As an alternative to adopting a particular project, we could build something. The WAF framework, for example, contains numerous infrastructure components that would facilitate building such a system. http://redhat.com/software/rha/tech/waf/ Community Projects: The ones I've looked at so far were mentioned in http://www.redhat.com/archives/fedora-desktop-list/2004-April/msg00058.html My overall conclusion is that Open Groupware and Horde are the strongest existing options. k5n.us (http://www.k5n.us/webcalendar.php) License: GPL Features: Decent PHP calendar implementaion. Does not appear to have groups, but allows creating calendar entries for multiple individuals in 'Waiting for Approval' State. Allows Export as iCal, vCal, or CSV. Allows import as vCal or CSV. Supports LDAP authentication. Database: MySQL, PostgreSQL, Oracle, DB2, Interbase or ODBC. Documentation: Pretty good documentation. Good documentation on the DB schema. UCal from the University of Washington (http://www.washington.edu/ucal/) License: BSD Style http://www.washington.edu/ucal/bsd.html Features: Java Servlets based calendar implementation. Allows import & export in iCal. Has users & groups. Code is of adequate to poor quality. Academic implementation. No built-in authentication mechanism other than simple plaintext passwords. Database code spread throughout as raw JDBC calls. Open Groupware (OpenGroupware.org) License: GPL & LGPL Features: Group Collaboration system descended from the SKYRiX groupware server. Supports group workspaces, calendaring, some document management. Integrates with IMAP for mail and LDAP for authentication. Written in Objective-C, some XML-RPC APIs for Java & perl being developed. Calendar integration works with Mozilla Calendar, Apple's iCal.app and generic WebDav. There is an OGo specific Evolution plugin being developed; I tried it on 1.4.5 and it was able to create entries on the server, but not view them in Evolution. OGo works with Ximian's Exchange Connector v1.2. The version recently released as Open Source by Ximian is 1.4.7, which does not work, but there is strong interest on the OGo lists in supporting it. OGo has a plugable database architecture, and currently supports PostgreSQL and FrontBase. OGo has basic localization support for Latin-1 charsets, but doesn't currently support language such as Chinese or Japanese. This is a planned feature. Horde (http://www.horde.org/) License: GPL & LGPL PHP based groupware system. Supports POP3/IMAP integration for mail, LDAP & SQL for contact management, and has calendaring. The calendar system now support import/export of iCal. It doesn't yet support group calendaring, but this is in development. Supports MySQL and PostgreSQL databases. KGroupware (http://kgroupware.org/) License: GPL Groupware/calendaring solution focusing on KDE frontends. Calendaring supports vCal standard. Calendar entries, like everything else, are stored on the IMAP server as a special type of 'mail' message. This does not fit well with most other software. http://www.redhat.com/archives/fedora-list/2003-October/msg00588.html Chandler (http://wiki.osafoundation.org/twiki/bin/view/Chandler/WebHome) License: GPL, other OS licenses in the future. Interesting project, but is in a very early stage. It doesn't look like full Full iCal compliance isn't scheduled until the 1.5 release, and it is currently on 0.3. It isn't clear if even this allows external clients such as Evolution to access calendar functionality. Currently, development focus is on building out the application framework. The project has full time developers being funded by OSAF. Egroupware: License: GPL & LGPL community Egroupware is a fork of phpgroupware. Some people were dissatisfied with phpgroupware development so they forked. The calendar application is actually on a fork of the PHP-based WebCalendar (separate project).The project is pretty popular as a download on sourceforge. features Reasonable calendar. Primitive "CMS". Webmail app (strangely not based on Horde; based on Anglemail). There is also a Wiki, Bookmarks, Forum, and "Infolog" (notes/todos).The UI isn't very good (lots of clicking around to figure out how to do things, and it's slow so it's a bit frustrating). It looks pretty, though.The documentation is pretty abysmal. There is work with LDAP. technical Written in PHP. It runs very slowly on a test system at Red Hat. Supports MySQL and PostgreSQL only with embedded SQL statements.They have made an attempt to separate out business logic from the UI. Given the scripting language base, I don't know if this is scaleable. Interoperability with existing systems (e.g., IMAP stores) does not seem to be a focus.They do not have real standards support (e.g., iCal). From wcohen at redhat.com Wed May 12 21:57:27 2004 From: wcohen at redhat.com (Will Cohen) Date: Wed, 12 May 2004 17:57:27 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <4099587F.4010200@redhat.com> References: <4099587F.4010200@redhat.com> Message-ID: <40A29DC7.8070908@redhat.com> An embedded and charset-unspecified text was scrubbed... Name: desktop4.txt URL: From jdennis at redhat.com Wed May 12 22:10:53 2004 From: jdennis at redhat.com (John Dennis) Date: Wed, 12 May 2004 18:10:53 -0400 Subject: Shared Calendars In-Reply-To: <40A2987E.7080600@redhat.com> References: <40A2987E.7080600@redhat.com> Message-ID: <1084399853.15782.367.camel@finch.boston.redhat.com> Thank you Jon for your excellent write up. We have reviewed the same set of options you list and have come to pretty much the same conclusions with respect to the items you list and the desired requirements. One thing you didn't list which we do feel is important is not only offering an open source calender server, but also providing a MS Exchange connection as this represents current reality for the corporate market we would like to penetrate. With open source clients this allows for a migration path from current proprietary installations to full open source. We are in the process of setting up and evaluating the OpenGroupware (OGo) suite as that now seems to be the strongest contender and I'm pleased to hear you also give it your nod. We also looked at Horde but drew the conclusion, perhaps hastily, it was too web centric. If you have other input or experiences that would help guide us we would love to get more input from you as it seems like you've had some experience in this area. John -- John Dennis From jwilliams at business.otago.ac.nz Wed May 12 22:22:55 2004 From: jwilliams at business.otago.ac.nz (John Williams) Date: Thu, 13 May 2004 10:22:55 +1200 Subject: Performance tuning the Fedora Desktop In-Reply-To: <40A29DC7.8070908@redhat.com> References: <4099587F.4010200@redhat.com> <40A29DC7.8070908@redhat.com> Message-ID: <1084400575.3758.9.camel@localhost.localdomain> On Wed, 2004-05-12 at 17:57 -0400, Will Cohen wrote: Lots of very encouraging stuff. Thanks Will. :-) > METRICS > > Unfortunately, many people's metrics for desktop applications were > literally eyeballed, click a menu item see how long it takes for the > result to occur. This is difficult to automate and script. We really A small comment: the only really meaningful metric from the user's point of view is "does it take too long?". This is a binary variable. It is of course totally subjective, but _that is the point_ --- "objective" considerations are not meaningful to users. What I am trying to say is that (I humbly suggest) you face two problems: first finding the most pressing problems; and then fixing them. Objective metrics help with the second, but not the first. Examples: 1) Clicking on the Nautilus desktop menu to open a terminal results in a noticeable delay before the window has appeared on the screen. For such a simple application it should be instantaneous (my rig is a 2,.4GHz Athlon with 767MB RAM). 2) Opening a PDF file with gv results in an instantaneous appearance of the window; using ggv takes about five seconds. 3) A noticeable delay starting gedit (same reasoning as per terminal). I know that these "simple" apps hide hidden complexity due to their gnomeyness, but again, that is irrelevant to users. I hope the above is useful. Please don't read it as bitching. I _love_ Fedora and GNOME, and I want to express my gratitude to those of you who have provided me with such an enjoyable computing environment. cheers, John -- ICQ: 261810463 AIM: johnfrombluff AOL: johnfrombluff MSN: johnwilliamsFromBluff at hotmail.com Yahoo: JohnFromBluff Jabber: jwilliamsFromBluff at jabber.org From stuart at terminus.co.uk Thu May 13 00:17:38 2004 From: stuart at terminus.co.uk (Stuart Children) Date: Thu, 13 May 2004 01:17:38 +0100 Subject: window managers In-Reply-To: <1084328966.2569.15.camel@localhost.localdomain> References: <1084328966.2569.15.camel@localhost.localdomain> Message-ID: <1084407457.2297.61.camel@hex.home.terminus.co.uk> Hey On Wed, 2004-05-12 at 03:29, Havoc Pennington wrote: > I'm triaging my bugs and there are a few sawfish issues that I know I > won't get around to fixing. Also at this point I think most people > wanting a more featureful WM are using a more maintained one Yes, that's my impression. Certainly I've not recommended Sawfish when people have asked me for something "better" than Metacity. > 1) if we have a random more-features WM in Core, I think it should > probably be one of the more maintained ones instead of Sawfish Agreed. If a WM was added to Core I would say just go for the most compliant one that has a good development team and simply the most users. I think picking out a clear winner would be impossible though. So I don't think one should be added... > 2) maybe the right path instead is to put extra WMs in Extras and only > the full desktop envs - gnome, kde, xfce, and classic (twm/xterm) - in > Core Definitely agreed. Once Extras exists in a better form then any WM that's simple enough to package by itself will get supplied by the community. With Extras obvious to any end user and easy to use, then all the WMs will be available and everybody's happy. Desktop environments that require not only a suite of packages but tighter integration with the rest of the system should be in Core. > 3) either way, pretty sure someone other than me should be maintaining > the package I've no interest in sawfish, sorry. :) However, as I mentioned on fedora-devel, I have enlightenment packages on the way. What does need to happen is for the system to be able to integrate with any random WM better. There are two areas I'd like to see work on with regard to this: 1) X/DE startup - it's currently a nightmare to follow. I think several of the scripts could be improved. Certainly hardcoded parts should be removed. See the "GDM Suggestion" thread for one particular item. 2) Making the DEs more tolerant of swapping out parts of their system (like the WM) with compatible alternatives. Also things like not having to run the gnome-panel (I did read some discussion on this, but didn't keep tracking it - perhaps this is in-hand). Personally I use many GTK based apps and I love some of the benefits a GNOME environment gives me (consistent fonts being a basic example). However, I've no need of particular services and definitely not of heavy applications (ie: the panel and nautilus). -- Stuart From feliciano.matias at free.fr Thu May 13 00:38:17 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 13 May 2004 02:38:17 +0200 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1084345202.5085.5.camel@marte.biciclete.ro> References: <4099587F.4010200@redhat.com> <1084345202.5085.5.camel@marte.biciclete.ro> Message-ID: <1084408693.1114.1.camel@localhost.localdomain> Le mer 12/05/2004 ? 09:00, Marius Andreiana a ?crit : > On Thu, 2004-05-06 at 00:11, Will Cohen wrote: > > What specific performance problems have people observed so far in the > > desktop? > when HDD is used by an application (copying a large file, updatedb...), > all the applications respond slow. The preemptible kernel patch should > solve this, but it's not enabled in FC2. > Thought about preemptible kernel patch : http://kerneltrap.org/node/view/2702 > -- > Marius Andreiana > Galuna - Solutii Linux in Romania > http://www.galuna.ro > From wtogami at redhat.com Thu May 13 08:28:43 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 12 May 2004 22:28:43 -1000 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1084345202.5085.5.camel@marte.biciclete.ro> References: <4099587F.4010200@redhat.com> <1084345202.5085.5.camel@marte.biciclete.ro> Message-ID: <40A331BB.80005@redhat.com> Marius Andreiana wrote: > On Thu, 2004-05-06 at 00:11, Will Cohen wrote: > >>What specific performance problems have people observed so far in the >>desktop? > > when HDD is used by an application (copying a large file, updatedb...), > all the applications respond slow. The preemptible kernel patch should > solve this, but it's not enabled in FC2. > Paraphrased from what Arjan van de Ven told me regarding kernel preempt. Arjan said, "preempt doesn't help for the desktop (1ms to 0.8ms latency you don't notice *at all*) but that 4K stacks does make a big dent" Warren said, "and overall runtime would be slower with preempt because the on-CPU cache is blown away more often" Arjan said, "and it generates worse IO patterns -> slower disk io" both aren't good for performance; worse disk IO means actually longer feeled latency but really, humans don't notice latency < 10ms or so. so anything below that is just fudzing with noise however disk IO and things like the VM before 4K stacks can cause delays (not latencys) far longer than that Warren Togami wtogami at redhat.com From julo at altern.org Thu May 13 08:35:17 2004 From: julo at altern.org (Julien Olivier) Date: Thu, 13 May 2004 09:35:17 +0100 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1084400575.3758.9.camel@localhost.localdomain> References: <4099587F.4010200@redhat.com> <40A29DC7.8070908@redhat.com> <1084400575.3758.9.camel@localhost.localdomain> Message-ID: <1084437317.3530.15.camel@julien> > 1) Clicking on the Nautilus desktop menu to open a terminal results in a > noticeable delay before the window has appeared on the screen. For such > a simple application it should be instantaneous (my rig is a 2,.4GHz > Athlon with 767MB RAM). > Maybe a bit off-topic, but the lack of launch feedback when opening a terminal via the desktop pop-up menu (as opposed as using System Tools -> Terminal) can make it *appear* even slower, or even broken. And the same thing for folders opened by nautilus: no launch feed-back makes it feel broken sometimes... -- Julien Olivier From wtogami at redhat.com Thu May 13 10:17:47 2004 From: wtogami at redhat.com (Warren Togami) Date: Thu, 13 May 2004 00:17:47 -1000 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1084437317.3530.15.camel@julien> References: <4099587F.4010200@redhat.com> <40A29DC7.8070908@redhat.com> <1084400575.3758.9.camel@localhost.localdomain> <1084437317.3530.15.camel@julien> Message-ID: <40A34B4B.1050005@redhat.com> Julien Olivier wrote: >>1) Clicking on the Nautilus desktop menu to open a terminal results in a >>noticeable delay before the window has appeared on the screen. For such >>a simple application it should be instantaneous (my rig is a 2,.4GHz >>Athlon with 767MB RAM). >> > > > Maybe a bit off-topic, but the lack of launch feedback when opening a > terminal via the desktop pop-up menu (as opposed as using System Tools > -> Terminal) can make it *appear* even slower, or even broken. And the > same thing for folders opened by nautilus: no launch feed-back makes it > feel broken sometimes... > I addressed this in my initial rant in this thread too. We need more fine granularity in application feedback control across the board. Warren From pmatilai at welho.com Thu May 13 12:37:26 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 13 May 2004 15:37:26 +0300 (EEST) Subject: Performance tuning the Fedora Desktop In-Reply-To: <40A29DC7.8070908@redhat.com> References: <4099587F.4010200@redhat.com> <40A29DC7.8070908@redhat.com> Message-ID: On Wed, 12 May 2004, Will Cohen wrote: -cat text file to xterm I wouldn't worry so much about xterm, gnome-terminal and konsole are far worse in terms of performance. I recently ran a couple of tests (which is why I noticed the xterm mark), just a relatively noisy rpmbuild of an application. On my IBM T40 the build times on otherwise idle box, and completely reproducable, give or take couple of seconds: xterm: ~1m 20s gnome-terminal: ~1m 40s konsole: ~1m 40s Building on a virtual console, redirecting output to /dev/null or a file were basically ~1:20 all. That's an awfully lot of time wasted waiting for software to build which lot of us do all the time :-/ For cat it's much more dramatic (obviously): time cat /usr/share/mime-info/gnome-vfs.keys on virtual console:~0.5s xterm: ~3.5s gnome-terminal: ~6.5s konsole: ~10.5s (not only is it slow but also corrupts the terminal leaving garbage on screen) Tests done on RHL 9'ish box, FWIW. - Panu - From pmatilai at welho.com Thu May 13 12:51:02 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 13 May 2004 15:51:02 +0300 (EEST) Subject: Performance tuning the Fedora Desktop In-Reply-To: References: <4099587F.4010200@redhat.com> <40A29DC7.8070908@redhat.com> Message-ID: On Thu, 13 May 2004, Panu Matilainen wrote: > On Wed, 12 May 2004, Will Cohen wrote: > > -cat text file to xterm > > I wouldn't worry so much about xterm, gnome-terminal and konsole are far > worse in terms of performance. Erm .. take that back - making them use same exact font xterm becomes actually slowest of them all. Still, it's sickening to think how much time gets wasted by printing pretty AA-fonts when nobody's actually looking (eg when compiling software) - Panu - From wcohen at redhat.com Thu May 13 13:22:51 2004 From: wcohen at redhat.com (Will Cohen) Date: Thu, 13 May 2004 09:22:51 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <1084400575.3758.9.camel@localhost.localdomain> References: <4099587F.4010200@redhat.com> <40A29DC7.8070908@redhat.com> <1084400575.3758.9.camel@localhost.localdomain> Message-ID: <40A376AB.5010607@redhat.com> John Williams wrote: > On Wed, 2004-05-12 at 17:57 -0400, Will Cohen wrote: > > Lots of very encouraging stuff. Thanks Will. :-) > > > >>METRICS >> >>Unfortunately, many people's metrics for desktop applications were >>literally eyeballed, click a menu item see how long it takes for the >>result to occur. This is difficult to automate and script. We really > > > A small comment: the only really meaningful metric from the user's point > of view is "does it take too long?". This is a binary variable. It is > of course totally subjective, but _that is the point_ --- "objective" > considerations are not meaningful to users. > > What I am trying to say is that (I humbly suggest) you face two > problems: first finding the most pressing problems; and then fixing > them. Objective metrics help with the second, but not the first. True users only cares about "does it take too long?" However, developers need to know why it takes too long. There are a lot of possible causes. Just telling the developers this is too slow will point out the problem but does suggest any fixes to correct the problem. The metrics were for the benefit of the developers. Reading though my write up again I realize that I don't really have timing listed clearly as a metric. I will make sure that is explicit in the revision. Wall clock time is what we are trying to reduce. Thanks for the comments. -Will > > Examples: > > 1) Clicking on the Nautilus desktop menu to open a terminal results in a > noticeable delay before the window has appeared on the screen. For such > a simple application it should be instantaneous (my rig is a 2,.4GHz > Athlon with 767MB RAM). > > 2) Opening a PDF file with gv results in an instantaneous appearance of > the window; using ggv takes about five seconds. > > 3) A noticeable delay starting gedit (same reasoning as per terminal). > > > I know that these "simple" apps hide hidden complexity due to their > gnomeyness, but again, that is irrelevant to users. > > I hope the above is useful. Please don't read it as bitching. I _love_ > Fedora and GNOME, and I want to express my gratitude to those of you who > have provided me with such an enjoyable computing environment. > > cheers, > > John From wtogami at redhat.com Thu May 13 13:24:21 2004 From: wtogami at redhat.com (Warren Togami) Date: Thu, 13 May 2004 03:24:21 -1000 Subject: Performance tuning the Fedora Desktop In-Reply-To: References: <4099587F.4010200@redhat.com> <40A29DC7.8070908@redhat.com> Message-ID: <40A37705.5080907@redhat.com> Panu Matilainen wrote: > > I recently ran a couple of tests (which is why I noticed the xterm mark), > just a relatively noisy rpmbuild of an application. On my IBM T40 the > build times on otherwise idle box, and completely reproducable, give or > take couple of seconds: > xterm: ~1m 20s > gnome-terminal: ~1m 40s > konsole: ~1m 40s > > Building on a virtual console, redirecting output to /dev/null or a file > were basically ~1:20 all. That's an awfully lot of time wasted waiting for > software to build which lot of us do all the time :-/ > > For cat it's much more dramatic (obviously): > time cat /usr/share/mime-info/gnome-vfs.keys on > virtual console:~0.5s > xterm: ~3.5s > gnome-terminal: ~6.5s > konsole: ~10.5s (not only is it slow but also corrupts the > terminal leaving garbage on screen) > > Tests done on RHL 9'ish box, FWIW. > > - Panu - In FC2 things have changed for the worse for gnome-terminal performance, where it has become far worse than both konsole and xterm. A GNOME developer explained to me that was the trade-off necessary in making gnome-terminal able to display unicode characters with pango. I do admit it is nice to have that ability, and it is awesome to see CJK characters working in gnome-terminal, but at the same time I wish it were faster. Very often I am forced to minimize my gnome-terminal sessions in order to prevent 100% CPU usage while using remote ssh sessions or building something locally. The bottleneck is always my terminal CPU usage. =( Warren Togami wtogami at redhat.com From otaylor at redhat.com Thu May 13 14:47:21 2004 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 13 May 2004 10:47:21 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <40A37705.5080907@redhat.com> References: <4099587F.4010200@redhat.com> <40A29DC7.8070908@redhat.com> <40A37705.5080907@redhat.com> Message-ID: <1084459641.29318.7.camel@localhost.localdomain> On Thu, 2004-05-13 at 09:24, Warren Togami wrote: > In FC2 things have changed for the worse for gnome-terminal performance, > where it has become far worse than both konsole and xterm. A GNOME > developer explained to me that was the trade-off necessary in making > gnome-terminal able to display unicode characters with pango. I do > admit it is nice to have that ability, and it is awesome to see CJK > characters working in gnome-terminal, but at the same time I wish it > were faster. Except for a rebuild FC1 and FC2 have *exactly* the same version of VTE... Regards, Owen -------------- 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 wcohen at redhat.com Thu May 13 15:44:16 2004 From: wcohen at redhat.com (Will Cohen) Date: Thu, 13 May 2004 11:44:16 -0400 Subject: Performance tuning the Fedora Desktop In-Reply-To: <409E2689.6070307@redhat.com> References: <4099587F.4010200@redhat.com> <409E2689.6070307@redhat.com> Message-ID: <40A397D0.4010403@redhat.com> Warren Togami wrote: > On a somewhat related note, the rhn-applet uses more than 30MB of > virtual memory. That is just WAY too big. Also look at its CPU time > after a few days running. The combined time of it doing *something* > seems a bit too much IMHO. Ick, 30MB and 16MB resident for the rhn-applet? I took a quick look at the rhn-applet-gui on RHEL3 and FC2-test 3. The applet has definitely gotten bloated. The RHN people just sit around the corner from me I might point this out to them. -Will On RHEL3 PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 2227 wcohen 25 10 12896 6872 2512 S N 0.0 2.7 21:13 1 rhn-applet-gu On FC2-test3 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9664 wcohen 25 10 29592 16m 22m S 0.0 3.2 0:00.45 rhn-applet-gui This applet is pulling in lots of libraries. Just counting the number of memory maps, no consideration about the amount of space for each map: RHEL 3 236 map entries 106 shared library code ( grep "r-xp" /tmp/rhn-app.map |grep ".so"|wc) 106 shared library data ( grep "rw-p" /tmp/rhn-app.map |grep ".so"|wc) 107 executable (grep "r-xp" /tmp/rhn-app.map |wc) 124 rw data (grep "rw-p" /tmp/rhn-app.map |wc) 2 ro data (grep "r--p" /tmp/rhn-app.map |wc) FC2-test3 270 map entries 115 shared library code ( grep "r-xp" /tmp/rhn-app.map |grep ".so"|wc) 115 shared library data ( grep "rw-p" /tmp/rhn-app.map |grep ".so"|wc) 117 executables (grep "r-xp" /tmp/rhn-app.map.fc2 |wc) 139 rw data (grep "rw-p" /tmp/rhn-app.map |wc) 10 ro data (grep "r--p" /tmp/rhn-app.map |wc) Files mapped into FC2-test3 but don't appear to be listed in RHEL3 +/lib/libcom_err.so.2.1 +/lib/libnss_files-2.3.3.so +/lib/libselinux.so.1 +/lib/tls/librt-2.3.3.so +/usr/lib/libasound.so.2.0.0 +/usr/lib/libgnome-keyring.so.0.0.0 +/usr/lib/libgssapi_krb5.so.2.2 +/usr/lib/libIDL-2.so.0.0.0 +/usr/lib/libk5crypto.so.3.0 +/usr/lib/libkrb5.so.3.2 +/usr/lib/libORBit-imodule-2.so.0.0.0 +/usr/lib/python2.3/lib-dynload/binascii.so +/usr/lib/python2.3/lib-dynload/md5module.so +/usr/lib/python2.3/lib-dynload/_random.so +/usr/lib/python2.3/lib-dynload/_ssl.so +/usr/lib/python2.3/site-packages/_xmlplus/parsers/pyexpat.so +/usr/X11R6/lib/libXcursor.so.1.0.2 From fzied at dottn.com Thu May 13 16:14:11 2004 From: fzied at dottn.com (Zied Fakhfakh) Date: Thu, 13 May 2004 17:14:11 +0100 Subject: XFce category Message-ID: Hi, I wonder if it is possible a subsection or category to fedora installer, where we can shoose to install XFce (like KDE or GNOME) Thanks. -- Zied Fakhfakh CTO - dot TN 1, Djebel Arafat Street Tel : +216 71 702265 Ariana sup?rieure - Ariana Fax : +216 71 702265 2080 - Tunisia Web : http://www.dottn.com From lists at edmack.com Fri May 14 08:50:31 2004 From: lists at edmack.com (Ed Mack) Date: Fri, 14 May 2004 09:50:31 +0100 Subject: XFce category In-Reply-To: References: Message-ID: <1084524379.4936.242.camel@localhost.localdomain> > I wonder if it is possible a subsection or category to fedora installer, > where we can shoose to install XFce (like KDE or GNOME) I don't really like this idea, as many users still stumble on KDE or Gnome (giving a screenshot of the default config for each would help them a bit) choice, I don't think more is the answer. I like Xfce, and I think that it should be in the apt/yum repositories as an option, but on that interested users must decide themselves as Xfce is really that great for beginners (take the file manager as an example), whereas KDE and Gnome bring the whole system together more cohesivly From jxlinuxer at 163.com Fri May 14 10:27:59 2004 From: jxlinuxer at 163.com (jxlinuxer) Date: Fri, 14 May 2004 18:27:59 +0800 Subject: Fedora-desktop-list Digest, Vol 3, Issue 14 Message-ID: <200405141021.i4EALIAX014114@mx3.redhat.com> hi! all, i just wanna know what's time the fc2 will out? i just hear someone said fc2 is halt. Best Regards, Jiaqi From foolish at guezz.net Fri May 14 19:55:18 2004 From: foolish at guezz.net (Sindre Pedersen Bjordal) Date: Fri, 14 May 2004 21:55:18 +0200 Subject: XFce category In-Reply-To: <1084524379.4936.242.camel@localhost.localdomain> References: <1084524379.4936.242.camel@localhost.localdomain> Message-ID: <1084564518.8705.4.camel@localhost.localdomain> fre, 14.05.2004 kl. 10.50 skrev Ed Mack: > > I wonder if it is possible a subsection or category to fedora installer, > > where we can shoose to install XFce (like KDE or GNOME) > > I don't really like this idea, as many users still stumble on KDE or > Gnome (giving a screenshot of the default config for each would help > them a bit) choice, I don't think more is the answer. I like Xfce, and I > think that it should be in the apt/yum repositories as an option, but on > that interested users must decide themselves as Xfce is really that > great for beginners (take the file manager as an example), whereas KDE > and Gnome bring the whole system together more cohesivly I think the fedora core should be kept as small or even smaller than it is now. The whole point of "core" is that it's the core, and if you want other things you can install them from some kind of extra source, maybe we can have a extra cd, that isn't required, containing these packages and other extra packages that some people need, but most can do without. We need to keep the core small, and then have a good, clear way for people to add extras. -- Sindre Pedersen Bjordal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From foolish at guezz.net Sat May 15 13:57:53 2004 From: foolish at guezz.net (Sindre Pedersen Bjordal) Date: Sat, 15 May 2004 15:57:53 +0200 Subject: XFce category In-Reply-To: <1084524379.4936.242.camel@localhost.localdomain> References: <1084524379.4936.242.camel@localhost.localdomain> Message-ID: <1084628949.4626.17.camel@localhost.localdomain> fre, 14.05.2004 kl. 10.50 skrev Ed Mack: > > I wonder if it is possible a subsection or category to fedora installer, > > where we can shoose to install XFce (like KDE or GNOME) > > I don't really like this idea, as many users still stumble on KDE or > Gnome (giving a screenshot of the default config for each would help > them a bit) choice, I don't think more is the answer. I like Xfce, and I > think that it should be in the apt/yum repositories as an option, but on > that interested users must decide themselves as Xfce is really that > great for beginners (take the file manager as an example), whereas KDE > and Gnome bring the whole system together more cohesivly I think the fedora core should be kept as small or even smaller than it is now. The whole point of "core" is that it's the core, and if you want other things you can install them from some kind of extra source, maybe we can have a extra cd, that isn't required, containing these packages and other extra packages that some people need, but most can do without. We need to keep the core small, and then have a good, clear way for people to add extras. -- Sindre Pedersen Bjordal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From foolish at guezz.net Sat May 15 13:57:52 2004 From: foolish at guezz.net (Sindre Pedersen Bjordal) Date: Sat, 15 May 2004 15:57:52 +0200 Subject: Fedora cd artwork: Covers, CD-labels etc. Message-ID: <1084628935.4626.15.camel@localhost.localdomain> I was wondering, do any of you know of any Fedora artwork that can be made into a cover and CD-label for my Fedora CD-set or maybe even some finished covers or cd-labels? If someone not as artistically retarded as me decided to make something like this, will it be ok (as in legal) to distribute it? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From gareth at fedoraforum.org Sat May 15 16:19:11 2004 From: gareth at fedoraforum.org (Gareth Russell) Date: Sat, 15 May 2004 17:19:11 +0100 Subject: Fedora cd artwork: Covers, CD-labels etc. In-Reply-To: <20040515160003.9D77573EB1@hormel.redhat.com> References: <20040515160003.9D77573EB1@hormel.redhat.com> Message-ID: <1084637950.2570.4.camel@localhost.localdomain> > I was wondering, do any of you know of any Fedora artwork that can be > made into a cover and CD-label for my Fedora CD-set or maybe even some > finished covers or cd-labels? > > If someone not as artistically retarded as me decided to make > something > like this, will it be ok (as in legal) to distribute it? I know that you can find the Fedora logos here as vectors: http://people.redhat.com/glesage/artwork/Fedora/fedora-core-logo.ai http://people.redhat.com/glesage/artwork/Fedora/fedora-core-logo.svg http://people.redhat.com/glesage/artwork/Fedora/fedora-project-logo.ai http://people.redhat.com/glesage/artwork/Fedora/fedora-project-logo.svg But i haven't found a large RedHat Fedora picture around. (You know the RedHat which is used in the start menu). Hope that helps. Gareth From alexl at redhat.com Mon May 17 07:40:33 2004 From: alexl at redhat.com (Alexander Larsson) Date: 17 May 2004 09:40:33 +0200 Subject: Fedora cd artwork: Covers, CD-labels etc. In-Reply-To: <1084637950.2570.4.camel@localhost.localdomain> References: <20040515160003.9D77573EB1@hormel.redhat.com> <1084637950.2570.4.camel@localhost.localdomain> Message-ID: <1084779632.20393.15.camel@localhost.localdomain> On Sat, 2004-05-15 at 18:19, Gareth Russell wrote: > > I was wondering, do any of you know of any Fedora artwork that can be > > made into a cover and CD-label for my Fedora CD-set or maybe even some > > finished covers or cd-labels? > > > > If someone not as artistically retarded as me decided to make > > something > > like this, will it be ok (as in legal) to distribute it? > > I know that you can find the Fedora logos here as vectors: > > http://people.redhat.com/glesage/artwork/Fedora/fedora-core-logo.ai > http://people.redhat.com/glesage/artwork/Fedora/fedora-core-logo.svg > http://people.redhat.com/glesage/artwork/Fedora/fedora-project-logo.ai > http://people.redhat.com/glesage/artwork/Fedora/fedora-project-logo.svg > > But i haven't found a large RedHat Fedora picture around. (You know the RedHat which is used in the start menu). > > Hope that helps. Actually, the red hat (a fedora even!) image used for the start menu is not really an official Red Hat logo or anything, its just a random red hat. I doubt it exists in a larger version. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a lounge-singing playboy filmmaker with a secret. She's a beautiful junkie opera singer trying to make a difference in a man's world. They fight crime! From gareth at fedoraforum.org Mon May 17 19:57:10 2004 From: gareth at fedoraforum.org (Gareth Russell) Date: Mon, 17 May 2004 20:57:10 +0100 Subject: Fedora cd artwork: Covers, CD-labels etc. In-Reply-To: <20040517160004.E41F273DF6@hormel.redhat.com> References: <20040517160004.E41F273DF6@hormel.redhat.com> Message-ID: <40A91916.9090902@fedoraforum.org> >>>I was wondering, do any of you know of any Fedora artwork that can be >>>made into a cover and CD-label for my Fedora CD-set or maybe even some >>>finished covers or cd-labels? >>> >>>If someone not as artistically retarded as me decided to make >>>something >>>like this, will it be ok (as in legal) to distribute it? >>> >>> >>I know that you can find the Fedora logos here as vectors: >> >>http://people.redhat.com/glesage/artwork/Fedora/fedora-core-logo.ai >>http://people.redhat.com/glesage/artwork/Fedora/fedora-core-logo.svg >>http://people.redhat.com/glesage/artwork/Fedora/fedora-project-logo.ai >>http://people.redhat.com/glesage/artwork/Fedora/fedora-project-logo.svg >> >>But i haven't found a large RedHat Fedora picture around. (You know the RedHat which is used in the start menu). >> >>Hope that helps. >> >> > >Actually, the red hat (a fedora even!) image used for the start menu is >not really an official Red Hat logo or anything, its just a random red >hat. I doubt it exists in a larger version. > > > That's a shame - I had been looking high and low for one for quite some time. Thanks for letting me know. From a.meyer at hccnet.nl Tue May 18 09:39:03 2004 From: a.meyer at hccnet.nl (a.meyer at hccnet.nl) Date: Tue, 18 May 2004 09:39:03 UT Subject: Fedora cd artwork: Covers, CD-labels etc. Message-ID: <200405180939.i4I9d3Ae021154@smtp10.hccnet.nl> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From stevelist at silverorange.com Tue May 18 12:47:03 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Tue, 18 May 2004 09:47:03 -0300 Subject: Bluecurve after Garrett Message-ID: <40AA05C7.3070709@silverorange.com> For those that haven't seen the news yet, Garrett LeSage, the designer of Bluecurve, is leaving RedHat: http://linuxart.com/news.phtml?sid=760 Garrett did great work and he will be missed. I wondered if anyone could shed some light on the future of Bluecurve and the visual aspects of Fedora/RHL in light of Garrett's departure. I understand that RedHat has been hiring or trying to hire some designers? Thanks, Steven Garrity From Sigmascape1 at cs.com Tue May 18 16:25:36 2004 From: Sigmascape1 at cs.com (Sigmascape1 at cs.com) Date: Tue, 18 May 2004 12:25:36 -0400 Subject: Fedora-desktop-list Digest, Vol 3, Issue 19 Message-ID: <17B5D3EE.26027A40.3F8EDD3A@cs.com> >From: Gareth Russell >Subject: Re: Fedora cd artwork: Covers, CD-labels etc. >To: fedora-desktop-list at redhat.com >Message-ID: <40A91916.9090902 at fedoraforum.org> >Content-Type: text/plain; charset=us-ascii; format=flowed > > >>>>I was wondering, do any of you know of any Fedora artwork that can be >>>>made into a cover and CD-label for my Fedora CD-set or maybe even some >>>>finished covers or cd-labels? >>>> >>>>If someone not as artistically retarded as me decided to make >>>>something >>>>like this, will it be ok (as in legal) to distribute it? >>>> ? ? ? >>>> >>>I know that you can find the Fedora logos here as vectors: >>> >>>http://people.redhat.com/glesage/artwork/Fedora/fedora-core-logo.ai >>>http://people.redhat.com/glesage/artwork/Fedora/fedora-core-logo.svg >>>http://people.redhat.com/glesage/artwork/Fedora/fedora-project-logo.ai >>>http://people.redhat.com/glesage/artwork/Fedora/fedora-project-logo.svg >>> >>>But i haven't found a large RedHat Fedora picture around. (You know the RedHat which is used in the start menu). >>> >>>Hope that helps. >>> ? ? >>> >> >>Actually, the red hat (a fedora even!) image used for the start menu is >>not really an official Red Hat logo or anything, its just a random red >>hat. I doubt it exists in a larger version. >> >> ? >> >That's a shame - I had been looking high and low for one for quite some >time. Thanks for letting me know. > I'd like to see a better Fedora logo. I assume the reason for its current design is that Red Hat may not have wanted Fedora to look like RH (or even close), but I could be wrong. The current Fedora logo is just too plain. Am I alone with this view? Thanks, Mitch Featherston From hp at redhat.com Tue May 18 17:14:31 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 18 May 2004 13:14:31 -0400 Subject: Bluecurve after Garrett In-Reply-To: <40AA05C7.3070709@silverorange.com> References: <40AA05C7.3070709@silverorange.com> Message-ID: <1084900471.5309.4.camel@localhost.localdomain> On Tue, 2004-05-18 at 08:47, Steven Garrity wrote: > For those that haven't seen the news yet, Garrett LeSage, the designer > of Bluecurve, is leaving RedHat: http://linuxart.com/news.phtml?sid=760 > > Garrett did great work and he will be missed. > > I wondered if anyone could shed some light on the future of Bluecurve > and the visual aspects of Fedora/RHL in light of Garrett's departure. I > understand that RedHat has been hiring or trying to hire some designers? > Indeed, we have a job listing: http://redhat.hrdpt.com/cgi-bin/a/highlightjob.cgi?jobid=82 Send resume and portfolio... I haven't gotten back to any applicants yet, but plan to start contacting some people soon. Havoc From fzied at dottn.com Tue May 18 17:35:40 2004 From: fzied at dottn.com (Zied Fakhfakh) Date: Tue, 18 May 2004 18:35:40 +0100 Subject: Fedora-desktop-list Digest, Vol 3, Issue 19 In-Reply-To: <17B5D3EE.26027A40.3F8EDD3A@cs.com> References: <17B5D3EE.26027A40.3F8EDD3A@cs.com> Message-ID: Sigmascape1 at cs.com wrote: >>From: Gareth Russell >>Subject: Re: Fedora cd artwork: Covers, CD-labels etc. >>To: fedora-desktop-list at redhat.com >>Message-ID: <40A91916.9090902 at fedoraforum.org> >>Content-Type: text/plain; charset=us-ascii; format=flowed >> >> >> >>>>>I was wondering, do any of you know of any Fedora artwork that can be >>>>>made into a cover and CD-label for my Fedora CD-set or maybe even some >>>>>finished covers or cd-labels? >>>>> >>>>>If someone not as artistically retarded as me decided to make >>>>>something >>>>>like this, will it be ok (as in legal) to distribute it? >>>>> >>>>> >>>> >>>>I know that you can find the Fedora logos here as vectors: >>>> >>>>http://people.redhat.com/glesage/artwork/Fedora/fedora-core-logo.ai >>>>http://people.redhat.com/glesage/artwork/Fedora/fedora-core-logo.svg >>>>http://people.redhat.com/glesage/artwork/Fedora/fedora-project-logo.ai >>>>http://people.redhat.com/glesage/artwork/Fedora/fedora-project-logo.svg >>>> >>>>But i haven't found a large RedHat Fedora picture around. (You know the RedHat which is used in the start menu). >>>> >>>>Hope that helps. >>>> >>>> >>> >>>Actually, the red hat (a fedora even!) image used for the start menu is >>>not really an official Red Hat logo or anything, its just a random red >>>hat. I doubt it exists in a larger version. >>> >>> >>> >> >>That's a shame - I had been looking high and low for one for quite some >>time. Thanks for letting me know. >> > > > I'd like to see a better Fedora logo. I assume the reason for its current design is that Red Hat may not have wanted Fedora to look like RH (or even close), but I could be wrong. The current Fedora logo is just too plain. > > Am I alone with this view? > > Thanks, > > Mitch Featherston > > I agree with you, may be a contest should be organized ? after all fedora is for the community, let its logo not be redhat one. Zied. From wtogami at redhat.com Wed May 19 09:49:49 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 18 May 2004 23:49:49 -1000 Subject: Firefox and Thunderbird for FC2 Message-ID: <40AB2DBD.3050106@redhat.com> Fedora Extras has published today firefox and thunderbird packages for FC1 and FC2. These packages have been heavily patched and polished to integrate nicely into the Preferred Applications framework of FC2. This means that you can go into the Preferences -> Preferred Applications chooser, select Firefox & Thunderbird, and the GNOME desktop should fully honor your choice of browser and mail client when clicking hyperlinks in various programs of FC2. http://www.fedora.us/wiki/FedoraHOWTO Please follow the directions on this page if you do not already use Fedora Extras. Report problems of firefox & thunderbird to bugzilla.fedora.us. http://togami.com/~warren/archive/2004/foxbird.sh FC1 users can also use firefox & thunderbird from the Fedora Extras stable repository, but unfortunately the Preferred Applications framework in FC1 is a bit broken. As a workaround you can run this script as your non-root user to set your profile to use these two applications. Warren Togami wtogami at redhat.com From yusufg at outblaze.com Fri May 21 11:30:43 2004 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Fri, 21 May 2004 19:30:43 +0800 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla Message-ID: <20040521113043.GB23226@outblaze.com> Hi, I installed Fedora Core 2 on an Athlon 750 with 512MB ram with an Nvidia Vanta II pci video card. After a fresh boot, I timed the following a) startup of Mozilla from the panel till Release notes was rendered b) startup of gnome-terminal from Fedora Menu->System Tools->Terminal till bash prompt The timings for a) and b) on 'cold-start' were 10 and 13 seconds respectively. On a 'warm cache' (ie) start Mozilla/shutdown/start again the timings were 3 and 11 seconds respectively. My expecation is that gnome-terminal is simpler/smaller than Mozilla and as such should startup much faster I was wondering if others saw similar ratio or is there something I might have missed Regards, Yusuf From walters at redhat.com Fri May 21 12:22:03 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 21 May 2004 08:22:03 -0400 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <20040521113043.GB23226@outblaze.com> References: <20040521113043.GB23226@outblaze.com> Message-ID: <1085142122.12897.3.camel@nexus.verbum.private> On Fri, 2004-05-21 at 07:30, Yusuf Goolamabbas wrote: > Hi, I installed Fedora Core 2 on an Athlon 750 with 512MB ram with an > Nvidia Vanta II pci video card. > > After a fresh boot, I timed the following > a) startup of Mozilla from the panel till Release notes was rendered > b) startup of gnome-terminal from Fedora Menu->System Tools->Terminal > till bash prompt > > The timings for a) and b) on 'cold-start' were 10 and 13 seconds > respectively. On a 'warm cache' (ie) start Mozilla/shutdown/start again > the timings were 3 and 11 seconds respectively. > > My expecation is that gnome-terminal is simpler/smaller than Mozilla and > as such should startup much faster My suspicion is that you have something crazy in your shell init files (e.g. ~/.bashrc). -------------- 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 pmatilai at welho.com Fri May 21 16:14:42 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 21 May 2004 19:14:42 +0300 (EEST) Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <1085142122.12897.3.camel@nexus.verbum.private> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> Message-ID: On Fri, 21 May 2004, Colin Walters wrote: > On Fri, 2004-05-21 at 07:30, Yusuf Goolamabbas wrote: > > Hi, I installed Fedora Core 2 on an Athlon 750 with 512MB ram with an > > Nvidia Vanta II pci video card. > > > > After a fresh boot, I timed the following > > a) startup of Mozilla from the panel till Release notes was rendered > > b) startup of gnome-terminal from Fedora Menu->System Tools->Terminal > > till bash prompt > > > > The timings for a) and b) on 'cold-start' were 10 and 13 seconds > > respectively. On a 'warm cache' (ie) start Mozilla/shutdown/start again > > the timings were 3 and 11 seconds respectively. > > > > My expecation is that gnome-terminal is simpler/smaller than Mozilla and > > as such should startup much faster > > My suspicion is that you have something crazy in your shell init files > (e.g. ~/.bashrc). ...or there's something wrong with DNS - all Gnome (and KDE for that matter) applications take AGES to start if DNS is failing. - Panu - From dawson at fnal.gov Fri May 21 16:22:24 2004 From: dawson at fnal.gov (Troy Dawson) Date: Fri, 21 May 2004 11:22:24 -0500 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> Message-ID: <40AE2CC0.1070009@fnal.gov> Panu Matilainen wrote: > On Fri, 21 May 2004, Colin Walters wrote: > > >>On Fri, 2004-05-21 at 07:30, Yusuf Goolamabbas wrote: >> >>>Hi, I installed Fedora Core 2 on an Athlon 750 with 512MB ram with an >>>Nvidia Vanta II pci video card. >>> >>>After a fresh boot, I timed the following >>>a) startup of Mozilla from the panel till Release notes was rendered >>>b) startup of gnome-terminal from Fedora Menu->System Tools->Terminal >>> till bash prompt >>> >>>The timings for a) and b) on 'cold-start' were 10 and 13 seconds >>>respectively. On a 'warm cache' (ie) start Mozilla/shutdown/start again >>>the timings were 3 and 11 seconds respectively. >>> >>>My expecation is that gnome-terminal is simpler/smaller than Mozilla and >>>as such should startup much faster >> >>My suspicion is that you have something crazy in your shell init files >>(e.g. ~/.bashrc). > > > ...or there's something wrong with DNS - all Gnome (and KDE for that > matter) applications take AGES to start if DNS is failing. > > - Panu - > > This was discussed earlier in the thread "Performance tuning the Fedora Desktop". I think Warren had the real explanation, though I'm certain there could be others. ----------- In FC2 things have changed for the worse for gnome-terminal performance, where it has become far worse than both konsole and xterm. A GNOME developer explained to me that was the trade-off necessary in making gnome-terminal able to display unicode characters with pango. I do admit it is nice to have that ability, and it is awesome to see CJK characters working in gnome-terminal, but at the same time I wish it were faster. Very often I am forced to minimize my gnome-terminal sessions in order to prevent 100% CPU usage while using remote ssh sessions or building something locally. The bottleneck is always my terminal CPU usage. =( Warren Togami ----------- From walters at redhat.com Fri May 21 17:30:23 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 21 May 2004 13:30:23 -0400 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <40AE2CC0.1070009@fnal.gov> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <40AE2CC0.1070009@fnal.gov> Message-ID: <1085160622.31663.0.camel@nexus.verbum.private> On Fri, 2004-05-21 at 12:22, Troy Dawson wrote: > This was discussed earlier in the thread "Performance tuning the Fedora > Desktop". I think Warren had the real explanation, though I'm certain there > could be others. > ----------- > In FC2 things have changed for the worse for gnome-terminal performance, where > it has become far worse than both konsole and xterm. A GNOME developer > explained to me that was the trade-off necessary in making gnome-terminal able > to display unicode characters with pango. Yeah but most of this performance hit comes from displaying large amounts of text, not just starting up and displaying your shell prompt. -------------- 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 otaylor at redhat.com Fri May 21 17:48:48 2004 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 21 May 2004 13:48:48 -0400 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <40AE2CC0.1070009@fnal.gov> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <40AE2CC0.1070009@fnal.gov> Message-ID: <1085161727.32088.9.camel@localhost.localdomain> On Fri, 2004-05-21 at 12:22, Troy Dawson wrote: > This was discussed earlier in the thread "Performance tuning the Fedora > Desktop". I think Warren had the real explanation, though I'm certain there > could be others. > ----------- > In FC2 things have changed for the worse for gnome-terminal performance, where > it has become far worse than both konsole and xterm. A GNOME developer > explained to me that was the trade-off necessary in making gnome-terminal able > to display unicode characters with pango. I do admit it is nice to have that > ability, and it is awesome to see CJK characters working in gnome-terminal, > but at the same time I wish it were faster. > > Very often I am forced to minimize my gnome-terminal sessions in order to > prevent 100% CPU usage while using remote ssh sessions or building something > locally. The bottleneck is always my terminal CPU usage. =( > > Warren Togami > ----------- As I said on the earlier thread, VTE is *EXACTLY THE SAME VERSION* in FC1 and FC2. Owen -------------- 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 yusufg at outblaze.com Fri May 21 23:06:54 2004 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Sat, 22 May 2004 07:06:54 +0800 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> Message-ID: <20040521230654.GA29975@outblaze.com> On Fri, May 21, 2004 at 07:14:42PM +0300, Panu Matilainen wrote: > On Fri, 21 May 2004, Colin Walters wrote: > > > My suspicion is that you have something crazy in your shell init files > > (e.g. ~/.bashrc). > > ...or there's something wrong with DNS - all Gnome (and KDE for that > matter) applications take AGES to start if DNS is failing. Forgot to mention that I did the test immediately after a fresh install so if there is something crazy in the shell init files, it wasn't added by me DNS works since I can browse the web using Mozilla During install, I enabled the firewall and allowed ssh in Regards, /yg From gardnerbiggs at houston.rr.com Sun May 23 12:27:22 2004 From: gardnerbiggs at houston.rr.com (J. Gardner Biggs) Date: Sun, 23 May 2004 07:27:22 -0500 Subject: Best place to start kernel-module for sound card? In-Reply-To: <20040521230654.GA29975@outblaze.com> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> Message-ID: <1085315242.2538.10.camel@gort> I just upgraded from FC1 to FC2 and for some reason my soundcard was not set up properly. Running /usr/bin/system-config-soundcard detected it and solved the problem for the current session, but after rebooting the kernel-module was not started. Also running # modprobe snd-ens1370 fixed the problem for the current session but it did not persist after rebooting. Where should I make changes to load this at each boot time? contents of: /etc/modprobe.conf # Note: for use under 2.4, changes must also be made to modules.conf! alias eth0 tulip alias usb-controller uhci-hcd alias snd-card-0 snd-ens1370 install sound-slot-0 /sbin/modprobe --first-time --ignore-install sound-slot-0 && { /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1 || :; } remove sound-slot-0 { /bin/aumix-minimal -f /etc/.aumixrc -S >/dev/null 2>&1 || :; } ; /sbin/modprobe -r --first-time --ignore-remove sound-slot-0 contents of: /etc/modules.conf alias eth0 tulip alias usb-controller usb-uhci alias sound-slot-0 es1370 post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1 || : pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S >/dev/null 2>&1 || : # Note: for use under 2.6, changes must also be made to modprobe.conf! or should I just put the modprobe snd-ens1370 in /etc/rc.local? Thanks for your help. From wcohen at redhat.com Mon May 24 15:36:32 2004 From: wcohen at redhat.com (Will Cohen) Date: Mon, 24 May 2004 11:36:32 -0400 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <20040521230654.GA29975@outblaze.com> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> Message-ID: <40B21680.5070208@redhat.com> Yusuf Goolamabbas wrote: > On Fri, May 21, 2004 at 07:14:42PM +0300, Panu Matilainen wrote: > >>On Fri, 21 May 2004, Colin Walters wrote: >> >> >>>My suspicion is that you have something crazy in your shell init files >>>(e.g. ~/.bashrc). >> >>...or there's something wrong with DNS - all Gnome (and KDE for that >>matter) applications take AGES to start if DNS is failing. > > > Forgot to mention that I did the test immediately after a fresh install > so if there is something crazy in the shell init files, it wasn't added > by me > > DNS works since I can browse the web using Mozilla > > During install, I enabled the firewall and allowed ssh in > > Regards, /yg I am working on tools and techniques to better measure the performance of desktop applications with the goal of improving performance of desktop applications. xterm would certainly be considered in the desktop. Could you do the fill out the following information and post the results of these simple experiments? These are still pretty rough procedures, but it will give us some ideas where to look. What is the hardware configuration of the system: Processor (output of /proc/cpuinfo): Memory: Harddisk drive: Video card: What is the software configuration of the system: kernel being used (uname -r): rpm versions of packages (rpm -qf `which xterm`): In each case you will need to exit the newly started xterm once it has started. What is the output of: /usr/bin/time xterm What is the output of (note that the output is going to be split between the current xterm and the new xterm: LD_DEBUG=statistics xterm Also get a memory map of the xterm: xterm & # will print out pid of background process. use the number below cat /proc/2201/maps > /tmp/xterm_maps As root run oprofile to find out which executables and libraries are being used: opcontrol --setup --vmlinux=/boot/vmlinux-`uname -r` --separate=library opcontrol --reset; opcontrol --start; xterm; opcontrol --shutdown opreport If there is a complaint about opcontrol not being able to find the kernel image, replace "--vmlinux=/boot/vmlinux-`uname -r`" with "--no-vmlinux". -Will From Sigmascape1 at cs.com Mon May 24 16:03:28 2004 From: Sigmascape1 at cs.com (Sigmascape1 at cs.com) Date: Mon, 24 May 2004 12:03:28 -0400 Subject: Installation Question/Opinion Message-ID: <569A43B6.2613C268.3F8EDD3A@cs.com> Hi, I need some input on installation of Fedora 2. Would you suggest that I not attempt to install Fedora 2 on a laptop running an Sony Vaio, Athlon 1 Ghz machine with 256MB RAM, aprx 2 years old? I am just worried about hardware issues. Thanks! Mitch Featherston From sopwith at redhat.com Mon May 24 17:47:00 2004 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 24 May 2004 13:47:00 -0400 Subject: Fedora Project Mailing Lists reminder Message-ID: This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events. To stay aware of news, subscribe to this list. fedora-list - For users of releases. If you want help with a problem installing or using , this is the list for you. fedora-test-list - For testers of test releases. If you would like to discuss experiences using TEST releases, this is the list for you. fedora-devel-list - For developers, developers, developers. If you are interested in helping create releases, this is the list for you. fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-legacy-announce - For announcements about the Fedora Legacy Project fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-de-list - For discussions about Fedora in the German language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw From tack at sault.org Mon May 24 22:24:10 2004 From: tack at sault.org (Jason Tackaberry) Date: Mon, 24 May 2004 18:24:10 -0400 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <40B21680.5070208@redhat.com> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> Message-ID: <1085437450.7861.1.camel@draco.sault.org> On Mon, 2004-05-24 at 11:36 -0400, Will Cohen wrote: > /usr/bin/time xterm I don't think this is especially meaningful. If you just want to test the time it takes to load, maybe you want something instead like: time xterm -e '' Cheers, Jason. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: This is a digitally signed message part URL: From yusufg at outblaze.com Tue May 25 11:52:56 2004 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Tue, 25 May 2004 19:52:56 +0800 Subject: Results from xterm startup experiment In-Reply-To: <40B21680.5070208@redhat.com> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> Message-ID: <20040525115256.GA2387@outblaze.com> I had already run prelink -avmR since I wasn't sure if my system was prelinked out of the box or it would do it a week/two weeks subsequently > What is the hardware configuration of the system: > > Processor (output of /proc/cpuinfo): processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping : 2 cpu MHz : 756.938 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips : 1482.75 > Memory: 512 MB > Harddisk drive: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:04.1 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci0000:00:04.1 ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio hda: ST36421A, ATA DISK drive Using cfq io scheduler > Video card: PCI Vanta +-01.0-[0000:01]----00.0 nVidia Corporation NV6 [Vanta/Vanta LT] > What is the software configuration of the system: > > kernel being used (uname -r): 2.6.5-1.358 > rpm versions of packages (rpm -qf `which xterm`): xterm-179-6.EL > > In each case you will need to exit the newly started xterm once it has > started. > > What is the output of: > > /usr/bin/time xterm 0.13user 0.02system 0:10.59elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1548minor)pagefaults 0swaps > > What is the output of (note that the output is going to be split > between the current xterm and the new xterm: > > LD_DEBUG=statistics xterm I did the followin LD_DEBUG=statistics xterm > xterm.stat 2>&1 16607: 16607: runtime linker statistics: 16607: total startup time in dynamic loader: 2864925 clock cycles 16607: time needed for relocation: 286987 clock cycles (10.0%) 16607: number of relocations: 0 16607: number of relocations from cache: 233 16607: number of relative relocations: 0 16607: time needed to load objects: 2246374 clock cycles (78.4%) 16608: 16608: runtime linker statistics: 16608: total startup time in dynamic loader: 409553 clock cycles 16608: time needed for relocation: 15915 clock cycles (3.8%) 16608: number of relocations: 0 16608: number of relocations from cache: 17 16608: number of relative relocations: 0 16608: time needed to load objects: 202630 clock cycles (49.4%) 16608: 16608: runtime linker statistics: 16608: final number of relocations: 15 16608: final number of relocations from cache: 17 16627: 16627: runtime linker statistics: 16627: total startup time in dynamic loader: 440201 clock cycles 16627: time needed for relocation: 17764 clock cycles (4.0%) 16627: number of relocations: 0 16627: number of relocations from cache: 17 16627: number of relative relocations: 0 16627: time needed to load objects: 207246 clock cycles (47.0%) 16627: 16627: runtime linker statistics: 16627: final number of relocations: 15 16627: final number of relocations from cache: 17 16607: 16607: runtime linker statistics: 16607: final number of relocations: 181 16607: final number of relocations from cache: 244 > > Also get a memory map of the xterm: > > xterm & > # will print out pid of background process. use the number below > cat /proc/2201/maps > /tmp/xterm_maps 00153000-00164000 r-xp 00000000 03:03 418694 /usr/X11R6/lib/libXft.so.2.1.2 00164000-00165000 rw-p 00011000 03:03 418694 /usr/X11R6/lib/libXft.so.2.1.2 00167000-001bd000 r-xp 00000000 03:03 407945 /usr/X11R6/lib/libXaw.so.7.0 001bd000-001c4000 rw-p 00055000 03:03 407945 /usr/X11R6/lib/libXaw.so.7.0 0023f000-00240000 r-xp 00000000 03:03 484894 /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2 00240000-00241000 rw-p 00000000 03:03 484894 /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2 00294000-00295000 r-xp 00000000 00:00 0 004e2000-00530000 r-xp 00000000 03:03 411752 /usr/X11R6/lib/libXt.so.6.0 00530000-00534000 rw-p 0004d000 03:03 411752 /usr/X11R6/lib/libXt.so.6.0 0065f000-0067a000 r-xp 00000000 03:03 484892 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 0067a000-0067c000 rw-p 0001b000 03:03 484892 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 006d3000-006e8000 r-xp 00000000 03:03 418727 /usr/X11R6/lib/libXmu.so.6.2 006e8000-006e9000 rw-p 00014000 03:03 418727 /usr/X11R6/lib/libXmu.so.6.2 00836000-00844000 r-xp 00000000 03:03 415906 /usr/X11R6/lib/libXpm.so.4.11 00844000-00845000 rw-p 0000d000 03:03 415906 /usr/X11R6/lib/libXpm.so.4.11 009c8000-009dd000 r-xp 00000000 03:03 552026 /lib/ld-2.3.3.so 009dd000-009de000 r--p 00014000 03:03 552026 /lib/ld-2.3.3.so 009de000-009df000 rw-p 00015000 03:03 552026 /lib/ld-2.3.3.so 009e1000-00af6000 r-xp 00000000 03:03 552290 /lib/tls/libc-2.3.3.so 00af6000-00af8000 r--p 00115000 03:03 552290 /lib/tls/libc-2.3.3.so 00af8000-00afa000 rw-p 00117000 03:03 552290 /lib/tls/libc-2.3.3.so 00afa000-00afc000 rw-p 00000000 00:00 0 00afe000-00aff000 r-xp 00000000 03:03 411855 /usr/lib/libutempter.so.0.5.5 00aff000-00b00000 rw-p 00000000 03:03 411855 /usr/lib/libutempter.so.0.5.5 00b23000-00b25000 r-xp 00000000 03:03 552293 /lib/libdl-2.3.3.so 00b25000-00b26000 r--p 00001000 03:03 552293 /lib/libdl-2.3.3.so 00b26000-00b27000 rw-p 00002000 03:03 552293 /lib/libdl-2.3.3.so 00b29000-00bee000 r-xp 00000000 03:03 418689 /usr/X11R6/lib/libX11.so.6.2 00bee000-00bf1000 rw-p 000c5000 03:03 418689 /usr/X11R6/lib/libX11.so.6.2 00bf3000-00c00000 r-xp 00000000 03:03 418690 /usr/X11R6/lib/libXext.so.6.4 00c00000-00c01000 rw-p 0000c000 03:03 418690 /usr/X11R6/lib/libXext.so.6.4 00c03000-00c13000 r-xp 00000000 03:03 418683 /usr/lib/libz.so.1.2.1.1 00c13000-00c14000 rw-p 0000f000 03:03 418683 /usr/lib/libz.so.1.2.1.1 00c16000-00c19000 r-xp 00000000 03:03 548460 /lib/libtermcap.so.2.0.8 00c19000-00c1a000 rw-p 00002000 03:03 548460 /lib/libtermcap.so.2.0.8 00c95000-00ca9000 r-xp 00000000 03:03 418718 /usr/X11R6/lib/libICE.so.6.3 00ca9000-00caa000 rw-p 00014000 03:03 418718 /usr/X11R6/lib/libICE.so.6.3 00caa000-00cac000 rw-p 00000000 00:00 0 00cae000-00cb5000 r-xp 00000000 03:03 418719 /usr/X11R6/lib/libSM.so.6.0 00cb5000-00cb6000 rw-p 00007000 03:03 418719 /usr/X11R6/lib/libSM.so.6.0 00d0c000-00d6a000 r-xp 00000000 03:03 418685 /usr/lib/libfreetype.so.6.3.5 00d6a000-00d71000 rw-p 0005e000 03:03 418685 /usr/lib/libfreetype.so.6.3.5 00d93000-00db6000 r-xp 00000000 03:03 418687 /usr/lib/libfontconfig.so.1.0.4 00db6000-00db9000 rw-p 00023000 03:03 418687 /usr/lib/libfontconfig.so.1.0.4 00db9000-00dba000 rw-p 00000000 00:00 0 00dbc000-00dc3000 r-xp 00000000 03:03 418691 /usr/X11R6/lib/libXrender.so.1.2.2 00dc3000-00dc4000 rw-p 00006000 03:03 418691 /usr/X11R6/lib/libXrender.so.1.2.2 00dc6000-00de3000 r-xp 00000000 03:03 418686 /usr/lib/libexpat.so.0.5.0 00de3000-00de5000 rw-p 0001d000 03:03 418686 /usr/lib/libexpat.so.0.5.0 00de7000-00def000 r-xp 00000000 03:03 418695 /usr/X11R6/lib/libXcursor.so.1.0.2 00def000-00df0000 rw-p 00007000 03:03 418695 /usr/X11R6/lib/libXcursor.so.1.0.2 00e1e000-00e20000 r-xp 00000000 03:03 484893 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 00e20000-00e21000 rw-p 00001000 03:03 484893 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 02e84000-02e95000 r-xp 00000000 03:03 552300 /lib/libnsl-2.3.3.so 02e95000-02e96000 r--p 00011000 03:03 552300 /lib/libnsl-2.3.3.so 02e96000-02e97000 rw-p 00012000 03:03 552300 /lib/libnsl-2.3.3.so 02e97000-02e99000 rw-p 00000000 00:00 0 08047000-0807e000 r-xp 00000000 03:03 410724 /usr/bin/xterm 0807e000-08086000 rw-p 00036000 03:03 410724 /usr/bin/xterm 08086000-0808c000 rw-p 00000000 00:00 0 0823a000-0832b000 rw-p 00000000 00:00 0 f6b99000-f6d55000 rw-p 00000000 00:00 0 f6e0e000-f6e14000 r--s 00000000 03:03 420228 /usr/lib/gconv/gconv-modules.cache f6e16000-f7016000 r--p 00000000 03:03 406983 /usr/lib/locale/locale-archive f701f000-f7024000 rw-p ffffc000 00:00 0 fee81000-ff000000 rw-p fff80000 00:00 0 ffffd000-ffffe000 ---p 00000000 00:00 0 > > As root run oprofile to find out which executables and libraries are > being used: > > opcontrol --setup --vmlinux=/boot/vmlinux-`uname -r` --separate=library > opcontrol --reset; opcontrol --start; xterm; opcontrol --shutdown > opreport arjan mentioned on IRC that oprofile needs APIC and this is not enabled on UP kernel so I can't give you this info Hope the above helps, Let me know if I can assist further Regards, Yusuf From wcohen at redhat.com Tue May 25 13:16:30 2004 From: wcohen at redhat.com (Will Cohen) Date: Tue, 25 May 2004 09:16:30 -0400 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <1085437450.7861.1.camel@draco.sault.org> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> <1085437450.7861.1.camel@draco.sault.org> Message-ID: <40B3472E.9060301@redhat.com> Jason Tackaberry wrote: > On Mon, 2004-05-24 at 11:36 -0400, Will Cohen wrote: > >>/usr/bin/time xterm > > > I don't think this is especially meaningful. If you just want to test > the time it takes to load, maybe you want something instead like: time > xterm -e '' > > Cheers, > Jason. > I wanted to see the number of major and minor page faults. Using "time" uses the shell's builtin time which doesn't return that information. Need to have the explicit path in there to avoid using the shell's builtin. -Will From wcohen at redhat.com Tue May 25 14:21:27 2004 From: wcohen at redhat.com (Will Cohen) Date: Tue, 25 May 2004 10:21:27 -0400 Subject: Results from xterm startup experiment In-Reply-To: <20040525115256.GA2387@outblaze.com> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> <20040525115256.GA2387@outblaze.com> Message-ID: <40B35667.4080603@redhat.com> Thanks for running the experiments. Yusuf Goolamabbas wrote: > I had already run prelink -avmR since I wasn't sure if my system was > prelinked out of the box or it would do it a week/two weeks subsequently > > >>What is the hardware configuration of the system: >> >>Processor (output of /proc/cpuinfo): > > > processor : 0 > vendor_id : AuthenticAMD > cpu family : 6 > model : 4 > model name : AMD Athlon(tm) Processor > stepping : 2 > cpu MHz : 756.938 > cache size : 256 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow > bogomips : 1482.75 > > >>Memory: > > > 512 MB > > >>Harddisk drive: > > ide: Assuming 33MHz system bus speed for PIO modes; override with > idebus=xx > VP_IDE: IDE controller at PCI slot 0000:00:04.1 > VP_IDE: chipset revision 16 > VP_IDE: not 100% native mode: will probe irqs later > VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci0000:00:04.1 > ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio > hda: ST36421A, ATA DISK drive > Using cfq io scheduler > > >>Video card: > > > PCI Vanta > > +-01.0-[0000:01]----00.0 nVidia Corporation NV6 [Vanta/Vanta LT] > > >>What is the software configuration of the system: >> >>kernel being used (uname -r): > > 2.6.5-1.358 > > >>rpm versions of packages (rpm -qf `which xterm`): > > > xterm-179-6.EL > >>In each case you will need to exit the newly started xterm once it has >>started. >> >>What is the output of: >> >>/usr/bin/time xterm > > > 0.13user 0.02system 0:10.59elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (0major+1548minor)pagefaults 0swaps 10.59 seconds elapsed? That seems rather long. To get a better lower bound and remove the human interaction you can run: /usr/bin/time xterm -e '' The output above indicates that xterm is not cpu-bound, only 0.15s of the time is cpu time. However, this test is not identical to bringing up an xterm via the menu, a different font is being used. It is possible that additional time is required because of the fonts. I need to find out how to select the same font as being used for the menu selected xterm. >>What is the output of (note that the output is going to be split >>between the current xterm and the new xterm: >> >>LD_DEBUG=statistics xterm > > > I did the followin > LD_DEBUG=statistics xterm > xterm.stat 2>&1 > > 16607: > 16607: runtime linker statistics: > 16607: total startup time in dynamic loader: 2864925 clock cycles > 16607: time needed for relocation: 286987 clock cycles (10.0%) > 16607: number of relocations: 0 > 16607: number of relocations from cache: 233 > 16607: number of relative relocations: 0 > 16607: time needed to load objects: 2246374 clock cycles (78.4%) > 16608: > 16608: runtime linker statistics: > 16608: total startup time in dynamic loader: 409553 clock cycles > 16608: time needed for relocation: 15915 clock cycles (3.8%) > 16608: number of relocations: 0 > 16608: number of relocations from cache: 17 > 16608: number of relative relocations: 0 > 16608: time needed to load objects: 202630 clock cycles (49.4%) > 16608: > 16608: runtime linker statistics: > 16608: final number of relocations: 15 > 16608: final number of relocations from cache: 17 > 16627: > 16627: runtime linker statistics: > 16627: total startup time in dynamic loader: 440201 clock cycles > 16627: time needed for relocation: 17764 clock cycles (4.0%) > 16627: number of relocations: 0 > 16627: number of relocations from cache: 17 > 16627: number of relative relocations: 0 > 16627: time needed to load objects: 207246 clock cycles (47.0%) > 16627: > 16627: runtime linker statistics: > 16627: final number of relocations: 15 > 16627: final number of relocations from cache: 17 > 16607: > 16607: runtime linker statistics: > 16607: final number of relocations: 181 > 16607: final number of relocations from cache: 244 > >>Also get a memory map of the xterm: >> >>xterm & >># will print out pid of background process. use the number below >>cat /proc/2201/maps > /tmp/xterm_maps Lots of mappings, which is usually the case for GUI programs. Is it always slow starting up an xterm regardless of number of other xterms already on the screen? I am wondering if the slow time is due to pulling all the libraries off the disk. If the xterm startup up faster when there are already xterms, on the screen that may indicate that the time is being dominated by pulling the shared libraries from the disk into memory. How much disk activity is there when you start up xterm? >>As root run oprofile to find out which executables and libraries are >>being used: >> >>opcontrol --setup --vmlinux=/boot/vmlinux-`uname -r` --separate=library >>opcontrol --reset; opcontrol --start; xterm; opcontrol --shutdown >>opreport > > > arjan mentioned on IRC that oprofile needs APIC and this is not enabled > on UP kernel so I can't give you this info Yes, I forgot that you may be running as UP kernel. I usually install the smp kernel so I can get that information. But given the low cpu usage, oprofile is probably not going to help much here. > Hope the above helps, Let me know if I can assist further > > Regards, Yusuf > > -Will From wcohen at redhat.com Tue May 25 15:01:53 2004 From: wcohen at redhat.com (Will Cohen) Date: Tue, 25 May 2004 11:01:53 -0400 Subject: Results from xterm startup experiment In-Reply-To: <20040525115256.GA2387@outblaze.com> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> <20040525115256.GA2387@outblaze.com> Message-ID: <40B35FE1.7010505@redhat.com> Which window manager are you using? gnome? gnome uses /usr/bin/gnome-terminal rather than xterm. -Will From snickell at redhat.com Tue May 25 19:20:41 2004 From: snickell at redhat.com (Seth Nickell) Date: Tue, 25 May 2004 15:20:41 -0400 Subject: Small features for improving Abby's experience Message-ID: <1085512840.3653.49.camel@localhost.localdomain> A collection of smaller features that have a relatively high impact-on-abby/work ratio: * A post it note feature that allows Abby to drop notes on her desktop, but also drag them to a panel edge where they stick on top (allowing notes to be irritating is key to standard use of notes as reminders). * Show file attachments (but not little attachments like keys?) as first class objects. File attachments are usually more important to Abby than their containing messages * Let Abby mark e-mail messages as tasks, and have due dates set on them. E-mail is the most common place for people to store todo items. Support this existing behavior better. * OO.o help by example: given any OO.o object in the paste buffer let people "Recreate by example", which steps through how to create that item. Most people learn best by example, and it also allows people to build on "things they've seen". With traditional help systems you have to figure out what things are called, and hope that there's specific documentation on an item. This way Abby can use existing documents and things she's seen (people have pretty good "wasn't there something...." memories) to do new things in her own documents. * Files and folders can be moved seemlessly between the panel and nautilus. The same items apply in both. In the distant future, allow snippets of text, images, and other document contents to be directly dragged in. Allows drag-and-drop to have the deferred property of cut and paste, but retains the nice physical aspect. Also allows for multiple items to be naturally in the "clipboard". * Integrate music player seamlessly with the desktop. Use the desktop interface as the primary piece of the music player, not an "extra". In other words, the play list itself lives on the panel. Allow the music browser to be a floating window. Flips the dominance between the window presence and the panel presence. * Mark relevant items as "sysadmin" in the .desktop files and provide a marker on the account that shows them or hides them. Cleans out the menus a lot for Abby. Also adds the possibility for Horatio to browse through a smaller admin-only tool set. * Provide the ability to turn menu items from a non-base set "on", using a checklist. This is *not* full menu editing, but should easily fill Abby's demand for menu editing. More importantly, it reduces pressure for constantly increasing menu sizes over time. On the backend, Horatio can define two application sets: default applications, and applications which are "allowed" but not default. * Collapse volume control to a single slider. * Preferences cleanup, focused around Abby * An improved calculator designed around quick, small "back of napkin" sort of calculations. Not modeled after the deficiencies of physical calculators. Abby will typically be working in another context, so a good calculator needs to be designed for running in small time windows, and make it very easy to get results into other apps. -- Seth Nickell :: Interaction Designer, Red Hat :: From aaron.bennett at olin.edu Tue May 25 19:25:09 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Tue, 25 May 2004 15:25:09 -0400 Subject: Small features for improving Abby's experience In-Reply-To: <1085512840.3653.49.camel@localhost.localdomain> References: <1085512840.3653.49.camel@localhost.localdomain> Message-ID: <40B39D95.9030805@olin.edu> This is great stuff. Who is Abby? From jdennis at redhat.com Tue May 25 19:31:45 2004 From: jdennis at redhat.com (John Dennis) Date: Tue, 25 May 2004 15:31:45 -0400 Subject: Small features for improving Abby's experience In-Reply-To: <40B39D95.9030805@olin.edu> References: <1085512840.3653.49.camel@localhost.localdomain> <40B39D95.9030805@olin.edu> Message-ID: <1085513505.15104.44.camel@finch.boston.redhat.com> On Tue, 2004-05-25 at 15:25, Aaron Bennett wrote: > This is great stuff. Who is Abby? She is the daughter of Mr. and Mrs. Normal :-) All kidding aside, test case knowledge worker. From djr at redhat.com Tue May 25 20:07:53 2004 From: djr at redhat.com (Daniel Reed) Date: Tue, 25 May 2004 16:07:53 -0400 (EDT) Subject: Small features for improving Abby's experience In-Reply-To: <1085512840.3653.49.camel@localhost.localdomain> References: <1085512840.3653.49.camel@localhost.localdomain> Message-ID: On 2004-05-25T15:20-0400, Seth Nickell wrote: ) * Mark relevant items as "sysadmin" in the .desktop files and provide a ) marker on the account that shows them or hides them. Cleans out the ) menus a lot for Abby. Also adds the possibility for Horatio to browse ) through a smaller admin-only tool set. If at all possible, I would like to steer away from the term "admin". In English, an administrator is a decision maker, director, executive, etc. It is a title of authority rather than a job description. (A telephone network administrator only gets his hands dirty working with POTS when cooking soup.) I am not sure how we got to using the term "system administrator", but it may cause [be causing?] undesirable social change. (Kinda like how calling creative works "intellectual property" is changing how people perceive creative works.) If Horatio really is an administrator, he would not be dealing with maintaining an individual system, he would be directing someone else in that regard. Maybe "sysmaint"? ) * An improved calculator designed around quick, small "back of napkin" ) sort of calculations. Not modeled after the deficiencies of physical ) calculators. Abby will typically be working in another context, so a ) good calculator needs to be designed for running in small time windows, ) and make it very easy to get results into other apps. The best calculator is probably quickly-gotten and easily-dismissed: Some hot key to pop up, type formula (input bar already has focus), hit Enter, hit Copy key (result is pre-selected), Escape to dismiss calculator entirely, hit paste key. No mouse, no looking at the screen, even. -- Daniel Reed http://people.redhat.com/djr/ Desktop and Cygwin From tack at sault.org Tue May 25 20:18:15 2004 From: tack at sault.org (Jason Tackaberry) Date: Tue, 25 May 2004 16:18:15 -0400 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <40B3472E.9060301@redhat.com> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> <1085437450.7861.1.camel@draco.sault.org> <40B3472E.9060301@redhat.com> Message-ID: <1085516295.7861.60.camel@draco.sault.org> On Tue, 2004-05-25 at 09:16 -0400, Will Cohen wrote: > I wanted to see the number of major and minor page faults. Using "time" > uses the shell's builtin time which doesn't return that information. > Need to have the explicit path in there to avoid using the shell's builtin. It's funny how you can use *nix for years and years and still pick up little bits like that one, which seem like conventional wisdom. It's also funny how you can use *nix for years and years, and think you know what you're talking about enough to second guess someone @redhat.com, and then promptly get put in your place. :) Sheepishly, Jason. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: This is a digitally signed message part URL: From markmc at redhat.com Tue May 25 20:31:05 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 25 May 2004 21:31:05 +0100 Subject: GDM accessibility support In-Reply-To: <1083022879.5757.16.camel@roadrash.rdu.redhat.com> References: <1083022879.5757.16.camel@roadrash.rdu.redhat.com> Message-ID: <1085517065.20586.110.camel@localhost.localdomain> Hey, I was asked by someone about accessibility support in GDM and although I knew GDM had some sort of accessibility support I didn't know what it was or how it worked. I've had a poke and here's what I can tell: * GDM now comes with a set of accessibility modules that can be used to detect certain events happening on the login screen * The two modules shipped with GDM by default are the "DwellMouseEvents" and the "KeyMouseEvents" modules. Both of them allow you to activate the onscreen keyboard from the login screen in different ways. The first by moving the mouse around in a predefined order and the second by clicking the mouse or pressing keys in a predefined way. Take a look at the configuration files in /etc/X11/gdm/modules on FC2. * If you set AddGtkModules=true and uncomment the GtkModulesList line from gdm.conf, you should be able to try this out. You'll also need to install the latest "gok" package from rawhide. I'd recommend setting Greeter=/usr/bin/gdmlogin in gdm.conf also because that seems to be the only way of testing the dwell listener. * So, to activate gok you should now be able to either hold Ctrl-k down for a second and leave go or move the mouse over the login window from top to bottom and then left to right. * gok then comes up, but I haven't figured out how to do anything with it. Its either that gok is broken or I'm missing something obvious. I'm guessing its the form - accessibility stuff is in the habit of being terribly broken :/ So, that's all I have time for now, but if someone had the time to do more on this I'd recommend for a start: - Figure out how to actually use gok once its activated - Get the gok in rawhide pushed to FC2-updates Cheers, Mark. From wcohen at redhat.com Tue May 25 20:31:27 2004 From: wcohen at redhat.com (Will Cohen) Date: Tue, 25 May 2004 16:31:27 -0400 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <1085516295.7861.60.camel@draco.sault.org> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> <1085437450.7861.1.camel@draco.sault.org> <40B3472E.9060301@redhat.com> <1085516295.7861.60.camel@draco.sault.org> Message-ID: <40B3AD1F.5090609@redhat.com> Jason Tackaberry wrote: > On Tue, 2004-05-25 at 09:16 -0400, Will Cohen wrote: > >>I wanted to see the number of major and minor page faults. Using "time" >>uses the shell's builtin time which doesn't return that information. >>Need to have the explicit path in there to avoid using the shell's builtin. > > > It's funny how you can use *nix for years and years and still pick up > little bits like that one, which seem like conventional wisdom. > > It's also funny how you can use *nix for years and years, and think you > know what you're talking about enough to second guess someone > @redhat.com, and then promptly get put in your place. :) Funny, I learned about passing xterm a command to execute from your email. :) > Sheepishly, > Jason. > Seriously, your email was fine. I am sure there will be things that people will need to correct me on, and I did learn something from the email. Remember the our goal is to improve the performance of the Linux Desktop, not to be correct every single time. -Will PS I learned today that gnome actually uses gnome-terminal rather than xterm. From tack at sault.org Tue May 25 20:50:08 2004 From: tack at sault.org (Jason Tackaberry) Date: Tue, 25 May 2004 16:50:08 -0400 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <40B3AD1F.5090609@redhat.com> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> <1085437450.7861.1.camel@draco.sault.org> <40B3472E.9060301@redhat.com> <1085516295.7861.60.camel@draco.sault.org> <40B3AD1F.5090609@redhat.com> Message-ID: <1085518208.7861.71.camel@draco.sault.org> On Tue, 2004-05-25 at 16:31 -0400, Will Cohen wrote: > Funny, I learned about passing xterm a command to execute from your > email. :) Well that's good to hear. :) The -e switch works with gnome-terminal too, incidentally. > Remember the our goal is to improve the performance of the Linux > Desktop, not to be correct every single time. True, being correct every single time doesn't hurt either. :) > PS I learned today that gnome actually uses gnome-terminal rather than > xterm. It does, and it definitely could stand some performance improvements. I don't think it's _vastly_ slower than xterm (once it's started), but it does often get in the way. I think it was Warren who mentioned that he has to minimize gnome-terminal when he's doing a noisy compile otherwise it significantly slows down. That's certainly true for me too (although I just toggle to another tab), but I'm not sure if the real problem is with gnome-terminal, pango, or the underlying font system -- or perhaps at layers even lower than that, like really bad or non-existent Render support in the video driver. Cheers, Jason. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 229 bytes Desc: This is a digitally signed message part URL: From dmalcolm at redhat.com Tue May 25 21:22:40 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 25 May 2004 17:22:40 -0400 Subject: Small features for improving Abby's experience In-Reply-To: <1085512840.3653.49.camel@localhost.localdomain> References: <1085512840.3653.49.camel@localhost.localdomain> Message-ID: <1085520160.19160.6.camel@dhcp64-231.boston.redhat.com> On Tue, 2004-05-25 at 15:20 -0400, Seth Nickell wrote: > A collection of smaller features that have a relatively high > impact-on-abby/work ratio: > [snip] > * Show file attachments (but not little attachments like keys?) as first > class objects. File attachments are usually more important to Abby than > their containing messages How would this look in the UI? > > * Let Abby mark e-mail messages as tasks, and have due dates set on > them. E-mail is the most common place for people to store todo items. > Support this existing behavior better. Evolution has half of this feature already. If you rightclick on an email and select "Follow Up" you can enter a day (and time) by which the email needs to be followed up. But it doesn't appear then in the tasks view. Would it be better to: (i) perhaps change the UI to make it more obvious what this feature does (ii) extend the "follow up" feature so that the emails do appear in the tasks view (probably by writing a new evolution-data-server backend that talks to the email store) (iii) have a way of creating a new task from an email that refers back to the email? (the easy, hackish approach) [snip] From lists at edmack.com Tue May 25 21:22:42 2004 From: lists at edmack.com (Ed Mack) Date: Tue, 25 May 2004 22:22:42 +0100 Subject: Small features for improving Abby's experience In-Reply-To: References: <1085512840.3653.49.camel@localhost.localdomain> Message-ID: <1085520162.4936.366.camel@localhost.localdomain> > The best calculator is probably quickly-gotten and easily-dismissed: Some > hot key to pop up, type formula (input bar already has focus), hit Enter, > hit Copy key (result is pre-selected), Escape to dismiss calculator > entirely, hit paste key. No mouse, no looking at the screen, even. That's a nice idea for power users, but no use for most, especially Abby. It must be easily discoverable, and easily laid out. Seth's idea of the napkin-back calculator is great, maybe if it could hang off the panel and always be in front so that users could quickly use it, then dismiss it. If after clicking the 'Calculate' button the answer pane was highlighted and maybe copied, it would be fast to use.. is such behaviour inconsistent therefore bad for Abby's overall world? I like the direction for the panel too. Ed From hp at redhat.com Tue May 25 21:29:34 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 25 May 2004 17:29:34 -0400 Subject: Small features for improving Abby's experience In-Reply-To: <1085520160.19160.6.camel@dhcp64-231.boston.redhat.com> References: <1085512840.3653.49.camel@localhost.localdomain> <1085520160.19160.6.camel@dhcp64-231.boston.redhat.com> Message-ID: <1085520574.4421.36.camel@localhost.localdomain> On Tue, 2004-05-25 at 17:22, David Malcolm wrote: > > Evolution has half of this feature already. If you rightclick on an > email and select "Follow Up" you can enter a day (and time) by which the > email needs to be followed up. But it doesn't appear then in the tasks > view. Would it be better to: > (i) perhaps change the UI to make it more obvious what this feature does > (ii) extend the "follow up" feature so that the emails do appear in the > tasks view (probably by writing a new evolution-data-server backend > that talks to the email store) > (iii) have a way of creating a new task from an email that refers back > to the email? (the easy, hackish approach) See: http://bugzilla.ximian.com/show_bug.cgi?id=45458 Havoc From wcohen at redhat.com Tue May 25 21:31:23 2004 From: wcohen at redhat.com (Will Cohen) Date: Tue, 25 May 2004 17:31:23 -0400 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <1085518208.7861.71.camel@draco.sault.org> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> <1085437450.7861.1.camel@draco.sault.org> <40B3472E.9060301@redhat.com> <1085516295.7861.60.camel@draco.sault.org> <40B3AD1F.5090609@redhat.com> <1085518208.7861.71.camel@draco.sault.org> Message-ID: <40B3BB2B.9070402@redhat.com> Jason Tackaberry wrote: > On Tue, 2004-05-25 at 16:31 -0400, Will Cohen wrote: > >>Funny, I learned about passing xterm a command to execute from your >>email. :) > > > Well that's good to hear. :) The -e switch works with gnome-terminal > too, incidentally. > > >>Remember the our goal is to improve the performance of the Linux >>Desktop, not to be correct every single time. > > > True, being correct every single time doesn't hurt either. :) It doesn't hurt to be correct. However, I knew some people that got into a wierd mindset with a perfect 4.0 (out of 4.0) grade point average. The 4.0 grade point became the object rather than learning, they had to avoid making mistakes and hurting the 4.0. >>PS I learned today that gnome actually uses gnome-terminal rather than >>xterm. > > > It does, and it definitely could stand some performance improvements. I > don't think it's _vastly_ slower than xterm (once it's started), but it > does often get in the way. > > I think it was Warren who mentioned that he has to minimize > gnome-terminal when he's doing a noisy compile otherwise it > significantly slows down. That's certainly true for me too (although I > just toggle to another tab), but I'm not sure if the real problem is > with gnome-terminal, pango, or the underlying font system -- or perhaps > at layers even lower than that, like really bad or non-existent Render > support in the video driver. > > Cheers, > Jason. This morning I played around with some profiling of gnome-terminal. I got a freely available text file from project Gutenberg.net, http://www.gutenberg.net/etext02/jarg422.txt. I wrote a cruddy little script call cattest to start up oprofile and cat the file, then shutdown oprofile. I ran this on the console of a 2.4GHz p4 machine with 512 MB of memory. The script is attached to this email. It requires an SMP kernel and needs to be run as root. After running the little script and installing the debuginfo rpms I was able to get some profiles. It looks like this particular machine has a reasonable video card (NVIDIA Quadro 4). Most of the are not for drawing stuff on the screen. One drawback is rpm with /usr/X11R6/bin/Xorg does not have an associated debuginfo rpm. I assume this is where the redendering happens and where people see the performance hit in gnome-terminal. The first opreport shows the overall view of which applications had samples and the shared libraries associated with them. The second opreport lists the function-by-function breakdown. Why so much 25% of the time in memchr and real_tolower? -Will $ opreport --long-filenames|more CPU: P4 / Xeon, speed 2387.54 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 100000 GLOBAL_POWER_E...| samples| %| ------------------ 109105 77.3520 /usr/bin/gnome-terminal GLOBAL_POWER_E...| samples| %| ------------------ 34940 32.0242 /lib/tls/libc-2.3.3.so 34762 31.8611 /usr/lib/libvte.so.4.1.1 23412 21.4582 /usr/lib/libglib-2.0.so.0.400.0 4527 4.1492 /usr/X11R6/lib/libXft.so.2.1.2 3126 2.8651 /lib/tls/libpthread-0.61.so 2843 2.6057 /usr/lib/libgobject-2.0.so.0.400.0 2419 2.2171 /usr/lib/libgdk-x11-2.0.so.0.400.0 1090 0.9990 /usr/lib/libgtk-x11-2.0.so.0.400.0 696 0.6379 /usr/X11R6/lib/libX11.so.6.2 549 0.5032 /usr/lib/libfreetype.so.6.3.5 298 0.2731 /usr/lib/gtk-2.0/2.4.0/engines/libbluecurve.so 258 0.2365 /usr/lib/libgthread-2.0.so.0.400.0 143 0.1311 /usr/X11R6/lib/libXrender.so.1.2.2 29 0.0266 /usr/bin/gnome-terminal 7 0.0064 /usr/lib/libfontconfig.so.1.0.4 6 0.0055 /usr/lib/libORBit-2.so.0.0.0 15215 10.7870 /usr/X11R6/bin/Xorg GLOBAL_POWER_E...| samples| %| ------------------ 12259 80.5718 /usr/X11R6/bin/Xorg 2956 19.4282 /lib/tls/libc-2.3.3.so 14393 10.2042 /no-vmlinux $ opreport image:/usr/bin/gnome-terminal -l --long-filenames|more CPU: P4 / Xeon, speed 2387.54 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 100000 samples % image name symbol name 16863 15.4558 /lib/tls/libc-2.3.3.so __GI_memchr 12146 11.1324 /usr/lib/libglib-2.0.so.0.400.0 real_tolower 7696 7.0538 /lib/tls/libc-2.3.3.so __GI_memcpy 5693 5.2179 /usr/lib/libvte.so.4.1.1 _vte_iso2022_process 5571 5.1061 /usr/lib/libvte.so.4.1.1 vte_terminal_send 4893 4.4847 /lib/tls/libc-2.3.3.so __GI_memset 3166 2.9018 /usr/lib/libvte.so.4.1.1 vte_sequence_handler_set_title_internal 2547 2.3344 /usr/lib/libglib-2.0.so.0.400.0 g_async_queue_length 2449 2.2446 /usr/lib/libglib-2.0.so.0.400.0 g_async_queue_push_unlocked 2394 2.1942 /usr/lib/libvte.so.4.1.1 vte_terminal_feed_child 2263 2.0741 /usr/lib/libvte.so.4.1.1 _vte_ring_insert_preserve 2152 1.9724 /usr/X11R6/lib/libXft.so.2.1.2 XftGlyphFontSpecRender 2127 1.9495 /usr/lib/libvte.so.4.1.1 __do_global_ctors_aux 1812 1.6608 /usr/lib/libvte.so.4.1.1 vte_invalidate_all 1718 1.5746 /lib/tls/libc-2.3.3.so _int_malloc 1522 1.3950 /usr/lib/libglib-2.0.so.0.400.0 g_unichar_xdigit_value 1470 1.3473 /usr/lib/libvte.so.4.1.1 vte_terminal_key_press 1305 1.1961 /lib/tls/libpthread-0.61.so __pthread_mutex_unlock_usercnt 1263 1.1576 /lib/tls/libpthread-0.61.so __pthread_mutex_lock_internal -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cattest URL: From alexl at redhat.com Wed May 26 05:59:06 2004 From: alexl at redhat.com (Alexander Larsson) Date: 26 May 2004 07:59:06 +0200 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <1085518208.7861.71.camel@draco.sault.org> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> <1085437450.7861.1.camel@draco.sault.org> <40B3472E.9060301@redhat.com> <1085516295.7861.60.camel@draco.sault.org> <40B3AD1F.5090609@redhat.com> <1085518208.7861.71.camel@draco.sault.org> Message-ID: <1085551146.20393.583.camel@localhost.localdomain> On Tue, 2004-05-25 at 22:50, Jason Tackaberry wrote: > I think it was Warren who mentioned that he has to minimize > gnome-terminal when he's doing a noisy compile otherwise it > significantly slows down. That's certainly true for me too (although I > just toggle to another tab), but I'm not sure if the real problem is > with gnome-terminal, pango, or the underlying font system -- or perhaps > at layers even lower than that, like really bad or non-existent Render > support in the video driver. Gnome-terminal is really not significantly slower than xterm if they are on par font-wise, i.e. you run xterm with an AA font, or pick a bitmapped font for gnome-terminal. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a fiendish one-eyed waffle chef who hangs with the wrong crowd. She's a scantily clad junkie schoolgirl with the soul of a mighty warrior. They fight crime! From fzied at dottn.com Wed May 26 10:57:09 2004 From: fzied at dottn.com (Zied Fakhfakh) Date: Wed, 26 May 2004 11:57:09 +0100 Subject: FC2 pcmcia starts after network ! Message-ID: Hi All, I installed FC2 on my old samsung VM7000 (equipped with a pcmcia network card). after reboot the interface eth0 doesn't start because the pcmcia statrs after the network ! I handled it by setting the pcmcia service to start (S09pcmcia) before network (S10network). Now, Each time I install FC2 I need to do that. would you please, who's maintaing that, fix it ? Thanks. -- Zied Fakhfakh From markmc at redhat.com Wed May 26 11:37:15 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 26 May 2004 12:37:15 +0100 Subject: FC2 pcmcia starts after network ! In-Reply-To: References: Message-ID: <1085571434.20586.142.camel@localhost.localdomain> Hi, On Wed, 2004-05-26 at 11:57, Zied Fakhfakh wrote: > Hi All, > > I installed FC2 on my old samsung VM7000 (equipped with a pcmcia network > card). > > after reboot the interface eth0 doesn't start because the pcmcia statrs > after the network ! > I handled it by setting the pcmcia service to start (S09pcmcia) before > network (S10network). > > Now, Each time I install FC2 I need to do that. would you please, who's > maintaing that, fix it ? 1) This list is for discussing development work on Fedora's desktop 2) Your problem has been reported many times. Try searching the fedora-list and fedora-test-list archives or bugzilla for more details. Cheers, Mark. From stuart at terminus.co.uk Wed May 26 12:25:47 2004 From: stuart at terminus.co.uk (Stuart Children) Date: Wed, 26 May 2004 13:25:47 +0100 Subject: GDM Suggestion In-Reply-To: <1083719675.4190.159.camel@hex.home.terminus.co.uk> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> <1083620813.1995.19.camel@laptop> <20040503215052.GA1793@nostromo.devel.redhat.com> <1083622210.3438.30.camel@localhost.localdomain> <20040503221523.GB3469@nostromo.devel.redhat.com> <1083719675.4190.159.camel@hex.home.terminus.co.uk> Message-ID: <20040526122547.GA8382@urchin.earth.li> Hi On Wed, May 05, 2004 at 02:14:36AM +0100, Stuart Children wrote: > I think the issue is that there are two tasks - choosing a session for > gdm, and choosing a session for startx. For former is handled fine at > login time by gdm's own code (currently disabled). The problem is really > when someone wants to change the gdm session whilst logged in. They use > switchdesk - but switchdesk is really designed for the other task, > namely choosing a session for startx. > > I propose we solve this by making switchdesk suitable for both tasks - > so it updates gdm (ie: set the appropriate gconf key) as well as startx > (ie: writes ~/.Xclients). The default would be to change the setting of > both, but you should be able to do one or the other. Obviously this > requires my initial proposal (that switchdesk uses the same session list > as gdm). There are varying ways you could do the UI for this - I'll try > to mock up some ideas tomorrow. Again, I am willing to do the coding on > this! Waited to see what differences switchdesk had in FC2... awareness of more desktops, but they're still hardcoded, and it still has the same flaws as before regarding gdm/startx usage. So, attached is a mockup of the kind of thing I'm suggesting. Comments welcome. If this is seen as a good solution, then I would be extremely keen to get the necessary changes into FC3, and as I mentioned above I'm happy to do the coding. Somone at RedHat just needs to say the word. :) Cheers -- Stuart -------------- next part -------------- A non-text attachment was scrubbed... Name: switchdesk.png Type: image/png Size: 5999 bytes Desc: not available URL: From snickell at redhat.com Wed May 26 15:14:16 2004 From: snickell at redhat.com (Seth Nickell) Date: Wed, 26 May 2004 11:14:16 -0400 Subject: Small features for improving Abby's experience In-Reply-To: <1085520160.19160.6.camel@dhcp64-231.boston.redhat.com> References: <1085512840.3653.49.camel@localhost.localdomain> <1085520160.19160.6.camel@dhcp64-231.boston.redhat.com> Message-ID: <1085584456.2652.1.camel@localhost.localdomain> > > > > * Let Abby mark e-mail messages as tasks, and have due dates set on > > them. E-mail is the most common place for people to store todo items. > > Support this existing behavior better. > > Evolution has half of this feature already. If you rightclick on an > email and select "Follow Up" you can enter a day (and time) by which the > email needs to be followed up. Its very important not to require a due date, and to make marking as a task very simple (I suspect we should just replace "important" with "task", or perhaps just put all important messages in the task list). Most tasks don't have due dates, per se, they are just reminders. -Seth From hp at redhat.com Wed May 26 15:53:00 2004 From: hp at redhat.com (Havoc Pennington) Date: Wed, 26 May 2004 11:53:00 -0400 Subject: Small features for improving Abby's experience In-Reply-To: <1085584456.2652.1.camel@localhost.localdomain> References: <1085512840.3653.49.camel@localhost.localdomain> <1085520160.19160.6.camel@dhcp64-231.boston.redhat.com> <1085584456.2652.1.camel@localhost.localdomain> Message-ID: <1085586780.932.14.camel@localhost.localdomain> On Wed, 2004-05-26 at 11:14, Seth Nickell wrote: > Its very important not to require a due date, and to make marking as a > task very simple (I suspect we should just replace "important" with > "task", or perhaps just put all important messages in the task list). > Most tasks don't have due dates, per se, they are just reminders. The thing that makes this suck most (to me, a representative nontechnical user - ha) in Evo today is that the calendar/todo is modal with email. The todo list and calendar should be in some way ever-present, and when getting a todo item or event via mail I should be able to add it without closing the mail. The little calendar drop-down on the clock might be much more useful if it were "events and todo items for today" for example, and when marking an email as a todo it could sort of fly up to that list or something. When an event is coming up the clock could sort of throb and make a chime noise or something. I don't know. Maybe it should be a dedicated gizmo and not a clock. Anyway, you get the general idea, calendar/todo are pesky as a separate app, they are more like a structure for your day that should be always available whatever you are working on. Havoc From sandmann at redhat.com Thu May 27 13:52:28 2004 From: sandmann at redhat.com (Soeren Sandmann Pedersen) Date: Thu, 27 May 2004 15:52:28 +0200 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <40B3BB2B.9070402@redhat.com> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> <1085437450.7861.1.camel@draco.sault.org> <40B3472E.9060301@redhat.com> <1085516295.7861.60.camel@draco.sault.org> <40B3AD1F.5090609@redhat.com> <1085518208.7861.71.camel@draco.sault.org> <40B3BB2B.9070402@redhat.com> Message-ID: <1085665946.4936.47.camel@localhost.localdomain> On Tue, 2004-05-25 at 23:31, Will Cohen wrote: > After running the little script and installing the debuginfo rpms I was > able to get some profiles. It looks like this particular machine has a > reasonable video card (NVIDIA Quadro 4). Most of the are not for drawing > stuff on the screen. > > One drawback is rpm with /usr/X11R6/bin/Xorg does not have an associated > debuginfo rpm. I assume this is where the redendering happens and where > people see the performance hit in gnome-terminal. > > The first opreport shows the overall view of which applications had > samples and the shared libraries associated with them. The second > opreport lists the function-by-function breakdown. Why so much 25% of > the time in memchr and real_tolower? > The memchr() hit comes from this function: static char * _vte_iso2022_find_nextctl(const char *p, size_t length) { char *ret; if (length == 0) { return NULL; } ret = memchr(p, '\033', length); ret = _vte_iso2022_better(ret, memchr(p, '\n', length)); ret = _vte_iso2022_better(ret, memchr(p, '\r', length)); ret = _vte_iso2022_better(ret, memchr(p, '\016', length)); ret = _vte_iso2022_better(ret, memchr(p, '\017', length)); #ifdef VTE_ISO2022_8_BIT_CONTROLS /* This breaks UTF-8 and other encodings which use the high bits. */ ret = _vte_iso2022_better(ret, memchr(p, 0x8e, length)); ret = _vte_iso2022_better(ret, memchr(p, 0x8f, length)); #endif return ret; } Since the _vte_iso2022_better() function basically returns the minimum of the two pointers a speedup is possible by - doing only one pass over the string instead of seven - stopping as soon as a control character is found. The attached patch makes the elapsed time drop from 14.1 seconds to 12.4 seconds on cat jarg22.txt. Soeren -------------- next part -------------- Index: iso2022.c =================================================================== RCS file: /cvs/gnome/vte/src/iso2022.c,v retrieving revision 1.50 diff -u -r1.50 iso2022.c --- iso2022.c 15 Sep 2003 18:57:33 -0000 1.50 +++ iso2022.c 27 May 2004 13:39:23 -0000 @@ -862,35 +862,31 @@ } static char * -_vte_iso2022_better(char *p, char *q) -{ - if (p == NULL) { - return q; - } - if (q == NULL) { - return p; - } - return MIN(p, q); -} - -static char * _vte_iso2022_find_nextctl(const char *p, size_t length) { char *ret; + int i; + if (length == 0) { return NULL; } - ret = memchr(p, '\033', length); - ret = _vte_iso2022_better(ret, memchr(p, '\n', length)); - ret = _vte_iso2022_better(ret, memchr(p, '\r', length)); - ret = _vte_iso2022_better(ret, memchr(p, '\016', length)); - ret = _vte_iso2022_better(ret, memchr(p, '\017', length)); + + for (i = 0; i < length; ++i) { + if (p[i] == '\033' || + p[i] == '\n' || + p[i] == '\r' || + p[i] == '\016' || + p[i] == '\017' #ifdef VTE_ISO2022_8_BIT_CONTROLS - /* This breaks UTF-8 and other encodings which use the high bits. */ - ret = _vte_iso2022_better(ret, memchr(p, 0x8e, length)); - ret = _vte_iso2022_better(ret, memchr(p, 0x8f, length)); + || + p[i] == 0x8e || + p[i] == 0x8f #endif - return ret; + ) { + return (char *)p + i; + } + } + return NULL; } static long From mclasen at redhat.com Thu May 27 13:57:37 2004 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 27 May 2004 09:57:37 -0400 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <1085665946.4936.47.camel@localhost.localdomain> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> <1085437450.7861.1.camel@draco.sault.org> <40B3472E.9060301@redhat.com> <1085516295.7861.60.camel@draco.sault.org> <40B3AD1F.5090609@redhat.com> <1085518208.7861.71.camel@draco.sault.org> <40B3BB2B.9070402@redhat.com> <1085665946.4936.47.camel@localhost.localdomain> Message-ID: <1085666257.1389.19.camel@golem.boston.redhat.com> On Thu, 2004-05-27 at 09:52, Soeren Sandmann Pedersen wrote: > On Tue, 2004-05-25 at 23:31, Will Cohen wrote: > > > After running the little script and installing the debuginfo rpms I was > > able to get some profiles. It looks like this particular machine has a > > reasonable video card (NVIDIA Quadro 4). Most of the are not for drawing > > stuff on the screen. > > > > One drawback is rpm with /usr/X11R6/bin/Xorg does not have an associated > > debuginfo rpm. I assume this is where the redendering happens and where > > people see the performance hit in gnome-terminal. > > > > The first opreport shows the overall view of which applications had > > samples and the shared libraries associated with them. The second > > opreport lists the function-by-function breakdown. Why so much 25% of > > the time in memchr and real_tolower? > > > > The memchr() hit comes from this function: > > static char * > _vte_iso2022_find_nextctl(const char *p, size_t length) > { > char *ret; > if (length == 0) { > return NULL; > } > ret = memchr(p, '\033', length); > ret = _vte_iso2022_better(ret, memchr(p, '\n', length)); > ret = _vte_iso2022_better(ret, memchr(p, '\r', length)); > ret = _vte_iso2022_better(ret, memchr(p, '\016', length)); > ret = _vte_iso2022_better(ret, memchr(p, '\017', length)); > #ifdef VTE_ISO2022_8_BIT_CONTROLS > /* This breaks UTF-8 and other encodings which use the high > bits. */ > ret = _vte_iso2022_better(ret, memchr(p, 0x8e, length)); > ret = _vte_iso2022_better(ret, memchr(p, 0x8f, length)); > #endif > return ret; > } > > > Since the _vte_iso2022_better() function basically returns the minimum > of the two pointers a speedup is possible by > > - doing only one pass over the string instead of seven > - stopping as soon as a control character is found. > > The attached patch makes the elapsed time drop from 14.1 seconds to 12.4 > seconds on cat jarg22.txt. > Wouldn't it be much easier to use strpbrk ? From behdad at cs.toronto.edu Thu May 27 14:05:17 2004 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Thu, 27 May 2004 10:05:17 -0400 Subject: FC2: gnome-terminal takes much longer to startup than Mozilla In-Reply-To: <1085666257.1389.19.camel@golem.boston.redhat.com> References: <20040521113043.GB23226@outblaze.com> <1085142122.12897.3.camel@nexus.verbum.private> <20040521230654.GA29975@outblaze.com> <40B21680.5070208@redhat.com> <1085437450.7861.1.camel@draco.sault.org> <40B3472E.9060301@redhat.com> <1085516295.7861.60.camel@draco.sault.org> <40B3AD1F.5090609@redhat.com> <1085518208.7861.71.camel@draco.sault.org> <40B3BB2B.9070402@redhat.com> <1085665946.4936.47.camel@localhost.localdomain> <1085666257.1389.19.camel@golem.boston.redhat.com> Message-ID: BTW, in Fedora can't we completely get rid of ISO 2202? I still have the problem that some spam mails can confuse my gnome-terminal such that it switches to east Asian characters. Need to do a reset to get back to a usable state. --behdad behdad.org From snickell at redhat.com Thu May 27 18:25:13 2004 From: snickell at redhat.com (Seth Nickell) Date: Thu, 27 May 2004 14:25:13 -0400 Subject: GDM Suggestion In-Reply-To: <20040526122547.GA8382@urchin.earth.li> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> <1083620813.1995.19.camel@laptop> <20040503215052.GA1793@nostromo.devel.redhat.com> <1083622210.3438.30.camel@localhost.localdomain> <20040503221523.GB3469@nostromo.devel.redhat.com> <1083719675.4190.159.camel@hex.home.terminus.co.uk> <20040526122547.GA8382@urchin.earth.li> Message-ID: <1085682313.3410.1.camel@localhost.localdomain> Switchdesk is toast. The way we should be handling it at this point is prompting when you login to a non-default session through gdm. "Do you want to make WindowMaker your default?" sort of thing. -Seth On Wed, 2004-05-26 at 13:25 +0100, Stuart Children wrote: > Hi > > On Wed, May 05, 2004 at 02:14:36AM +0100, Stuart Children wrote: > > I think the issue is that there are two tasks - choosing a session for > > gdm, and choosing a session for startx. For former is handled fine at > > login time by gdm's own code (currently disabled). The problem is really > > when someone wants to change the gdm session whilst logged in. They use > > switchdesk - but switchdesk is really designed for the other task, > > namely choosing a session for startx. > > > > I propose we solve this by making switchdesk suitable for both tasks - > > so it updates gdm (ie: set the appropriate gconf key) as well as startx > > (ie: writes ~/.Xclients). The default would be to change the setting of > > both, but you should be able to do one or the other. Obviously this > > requires my initial proposal (that switchdesk uses the same session list > > as gdm). There are varying ways you could do the UI for this - I'll try > > to mock up some ideas tomorrow. Again, I am willing to do the coding on > > this! > > Waited to see what differences switchdesk had in FC2... awareness of more > desktops, but they're still hardcoded, and it still has the same flaws as > before regarding gdm/startx usage. > > So, attached is a mockup of the kind of thing I'm suggesting. Comments > welcome. > > If this is seen as a good solution, then I would be extremely keen to get > the necessary changes into FC3, and as I mentioned above I'm happy to do > the coding. Somone at RedHat just needs to say the word. :) > > Cheers > From wcohen at redhat.com Thu May 27 20:21:38 2004 From: wcohen at redhat.com (Will Cohen) Date: Thu, 27 May 2004 16:21:38 -0400 Subject: gnome-terminal benchmark Message-ID: <40B64DD2.6080508@redhat.com> In an effort to create a set of benchmarks for gauging desktop performance I have written up a procedure for gnome-terminal to test the speed that text is sent to the terminal window and written a script to perform the test. I have attached the writeup for the procedure (bench_terminal.txt) and the script to run the test (cattest) to this email. I am interested in hearing people's comments on this test. I know this is only one test and doesn't address desktop issues like program startup time, but we have to start somewhere. We can start to assemble the benchmarks and put them in http://fedora.redhat.com/projects/additional-projects/benchmarks/ -Will -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bench_terminal.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cattest URL: From florian at idelberger.de Thu May 27 20:52:27 2004 From: florian at idelberger.de (Florian Idelberger) Date: Thu, 27 May 2004 22:52:27 +0200 Subject: gnome-terminal benchmark In-Reply-To: <40B64DD2.6080508@redhat.com> References: <40B64DD2.6080508@redhat.com> Message-ID: <40B6550B.2000706@idelberger.de> This is what I got with the benchmark. I'd like to compare it with others. Mine was tested on a thoshiba 1400-503 (1.3Ghz) running fc2, 256 MB Ram. Benchmark: cattest Version: 0.0 Do Mai 27 22:49:22 CEST 2004 0.00user 0.09system 0:15.82elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+122minor)pagefaults 0swaps Will Cohen wrote: > In an effort to create a set of benchmarks for gauging desktop > performance I have written up a procedure for gnome-terminal to test > the speed that text is sent to the terminal window and written a > script to perform the test. I have attached the writeup for the > procedure (bench_terminal.txt) and the script to run the test > (cattest) to this email. > > I am interested in hearing people's comments on this test. I know this > is only one test and doesn't address desktop issues like program > startup time, but we have to start somewhere. > > We can start to assemble the benchmarks and put them in > > http://fedora.redhat.com/projects/additional-projects/benchmarks/ > > -Will > >------------------------------------------------------------------------ > >Benchmark text output performance of gnome-terminal > >Frequently output is sent to a terminal window. In Gnome the program >gnome-terminal handles the display of text on a terminal window. The, >one simple benchmark is to determine the amount of time required to >output a large text file to a gnome-terminal window. > >gnome-terminal is a little tricky to benchmark because has a >server. When you start gnome-terminal it connects to the server rather >than starting a new child process. Thus, timing the gnome-terminal >command will count the time required to communicate information to the >gnome-terminal server rather than the time required to actually >perform the task. To work around this problem a script is executed >within the new gnome-terminal window and the information is saved to a >file. > > >Procedure: > >0) Get system configuration information hardware and software: > CPU: cat /proc/cpuinfo > Memory: cat /proc/meminfo > Kernel: uname -a > gnome-terminal: rpm -qa gnome-terminal > xserver: rpm -qa xorg-x11 > >1) Get the test file, the jargon file from Project Gutenberg: > > http://www.gutenberg.net/etext02/jarg422.txt. > >2) Verify that the file is the same with md5sum > $ md5sum jarg422.txt > ef9b53f52312ee266c98c8e206d9e823 jarg422.txt > >3) Place the cattest script in the same directory as jarg422.txt and > make it executable. > >4) Run the test on the console of the machine with the command > below. The script will generate a file "cattime in the directory > with the amount of time required to cat the file to the terminal > window. > > gnome-terminal -e "./cattest" > >4a) If the system is set up to run oprofile and you have root access, > you can run the same script as root with command below to get some > additional profiling information in the cattime file: > > gnome-terminal -e "./cattest --profile" > > Additional analysis on the oprofile data can be performed after > the benchmark completes. > > >------------------------------------------------------------------------ > >#! /bin/bash ># ># Simple test to gather data on where gnome-terminal spends ># time This is compilicated by the terminal server model of ># gnome-terminal. Time taken for benchmark written to cattime. ># ># When optional --profile on commandline, oprofile used to get an ># overall view of what is happening on the system. PROFILING is only ># going to work with kernel that have oprofile support (Red Hat SMP ># kernels). ># ># Will Cohen ># 5/27/2004 ># > >BENCHMARK="cattest" >VERSION=0.0 > >OPCONTROL=/usr/bin/opcontrol >OPREPORT=/usr/bin/opreport >RM=/bin/rm >RESULTS_FILE=cattime > >if test "$1" = "--profile"; then > PROFILING=yes >else > PROFILING=no >fi > ># Setup default oprofile. >if test "$PROFILING" = "yes"; then > $OPCONTROL --deinit > $OPCONTROL --reset > # FIXME Command below may use previous event settings for oprofile. > $OPCONTROL --setup --no-vmlinux --separate=library > $OPCONTROL --start >fi > ># Run the actual experiment >$RM -rf $RESULTS_FILE >echo "Benchmark: " $BENCHMARK " Version: " $VERSION >> $RESULTS_FILE >date >> $RESULTS_FILE > ># The actual benchmark being timed is below. >/usr/bin/time /bin/cat `pwd`/jarg422.txt 2>> $RESULTS_FILE > ># Shutdown oprofile. >if test "$PROFILING" = "yes"; then > $OPCONTROL --dump > $OPCONTROL --shutdown > # If PROFILING, need to do analysis with oprerport after running the test. > # May need more details than what is provided by command below. > $OPREPORT --threshold 2 --long-filenames >> $RESULTS_FILE >fi > > From stuart at terminus.co.uk Thu May 27 22:35:52 2004 From: stuart at terminus.co.uk (Stuart Children) Date: Thu, 27 May 2004 23:35:52 +0100 Subject: GDM Suggestion In-Reply-To: <1085682313.3410.1.camel@localhost.localdomain> References: <20040501133919.GA4525@jadzia.bu.edu> <1083423855.2242.4.camel@localhost.localdomain> <1083453697.3572.20.camel@fc1> <1083470937.2242.41.camel@localhost.localdomain> <1083508855.23877.13.camel@localhost.localdomain> <1083620813.1995.19.camel@laptop> <20040503215052.GA1793@nostromo.devel.redhat.com> <1083622210.3438.30.camel@localhost.localdomain> <20040503221523.GB3469@nostromo.devel.redhat.com> <1083719675.4190.159.camel@hex.home.terminus.co.uk> <20040526122547.GA8382@urchin.earth.li> <1085682313.3410.1.camel@localhost.localdomain> Message-ID: <1085697352.3465.28.camel@hex.home.terminus.co.uk> On Thu, 2004-05-27 at 19:25, Seth Nickell wrote: > Switchdesk is toast. The way we should be handling it at this point is > prompting when you login to a non-default session through gdm. > > "Do you want to make WindowMaker your default?" sort of thing. Yes indeed... > On Wed, 2004-05-26 at 13:25 +0100, Stuart Children wrote: > > On Wed, May 05, 2004 at 02:14:36AM +0100, Stuart Children wrote: > > > I think the issue is that there are two tasks - choosing a session for > > > gdm, and choosing a session for startx. For former is handled fine at > > > login time by gdm's own code (currently disabled). ... which as has been mentioned is exactly what the standard (upstream) session chooser already does! It also address the other problem I mentioned (of automatically picking up which "desktops" are installed - by using .desktop files). This was enabled in RH9 IIRC. However, it does *not* address the latter task - namely, being able to select a desktop for using with startx. Now, if the consensus is that those people should edit their own .Xclients, fine - but there are already messages in this thread saying we want a tool for that. Which is presumably why FC is currently using switchdesk - presumably to have consistency between what you get when trying to change sesson in gdm and whilst actually within a session. However, switchdesk is flawed for reasons I have already explained. Part of its functions are still needed though, so we need a replacement (or basically, to rewrite it). To be specific, what I'm proposing is: * Change gdm to use its standard session chooser - making FC more "standard" with other GNOME desktops, closer to upstream, and giving you behaviour you mentioned above. * Rewrite switchdesk so that it offers the same list of desktops that the gdm session chooser does by using the same .desktop files. * Change the gui of switchdesk to clearly set the session for 1) logging in graphically [1], and 2) logging in on the console (ie: startx). This is what my mockup is for. [1] Granted, this is bad because it duplicates functionality - however, users will try and change their session whilst within X. If there is a tool there that appears to do what they want, but doesn't (because it's actually only for console X startup) they *will* be confused. As most of the code will be there anyway (for .Xclients generation), the only extra thing you're adding is the code to set the gconf key or whatever gdm uses to decide what your current default session is. When you say "Switchdesk is toast" - I agree it should be! I'm trying to discuss a replacement. Is someone in RedHat working on this, or has a decision been made regarding the startx use-case? If so, please let us know. Otherwise, I'd like to help implement this. Cheers -- Stuart From strange at nsk.no-ip.org Fri May 28 10:19:39 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 28 May 2004 11:19:39 +0100 Subject: gnome-terminal benchmark In-Reply-To: <40B64DD2.6080508@redhat.com> References: <40B64DD2.6080508@redhat.com> Message-ID: <20040528101939.GA11833@nsk.no-ip.org> On Thu, May 27, 2004 at 04:21:38PM -0400, Will Cohen wrote: > # The actual benchmark being timed is below. > /usr/bin/time /bin/cat `pwd`/jarg422.txt 2>> $RESULTS_FILE You're profiling cat under gnome-terminal, not gnome-terminal + cat. Wouldn't be better to run instead: /usr/bin/time gnome-terminal -x cat $PWD/jarg422.txt Regards, Luciano Rocha From wcohen at redhat.com Fri May 28 13:16:18 2004 From: wcohen at redhat.com (Will Cohen) Date: Fri, 28 May 2004 09:16:18 -0400 Subject: gnome-terminal benchmark In-Reply-To: <20040528101939.GA11833@nsk.no-ip.org> References: <40B64DD2.6080508@redhat.com> <20040528101939.GA11833@nsk.no-ip.org> Message-ID: <40B73BA2.4010707@redhat.com> Luciano Miguel Ferreira Rocha wrote: > On Thu, May 27, 2004 at 04:21:38PM -0400, Will Cohen wrote: > >># The actual benchmark being timed is below. >>/usr/bin/time /bin/cat `pwd`/jarg422.txt 2>> $RESULTS_FILE > > > You're profiling cat under gnome-terminal, not gnome-terminal + cat. > > Wouldn't be better to run instead: > /usr/bin/time gnome-terminal -x cat $PWD/jarg422.txt You are correct that this also includes the time for the cat. I tried that earlier there are comments on that in the procedure. The net result with the suggested change on gnome-terminal is that you get the amount of time it takes to fire off the command to the gnome-terminal server, not the amount of time to complete the task. The /usr/bin/time will finish long before the cat is actually done. Doing something like that on xterm you will get gnome-terminal + cat time. The goal of the benchmark was to make something that could provide some indication about the amount of time required to push a lot of text to a terminal window, exercise some of the gnome-terminal code, be reasonably easy to run, and have some chance at being repeatable. That the exeperiment includes time for cat is not that big an issue, so long the amount of time for cat stays the same and cat times don't totally dominate the time. If you have oprofile setup and run the benchmark with "--profile" you can see that xterm dominates the cpu by a large margin, about 75% of the samples. Just to get an idea of the time spent on cat for the test I did the following on a 2.4GHz P4 with 512M memory running fc2: $ /usr/bin/time /bin/cat /home/wcohen/jarg422.txt > /dev/null 0.00user 0.00system 0:00.57elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+106minor)pagefaults 0swaps $ /usr/bin/time /bin/cat /home/wcohen/jarg422.txt > /dev/null 0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+105minor)pagefaults 0swaps $ /usr/bin/time /bin/cat /home/wcohen/jarg422.txt > /dev/null 0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+104minor)pagefaults 0swaps $ /usr/bin/time /bin/cat /home/wcohen/jarg422.txt > /dev/null It probably would be a good idea to have the script run the test multiple times to make sure that jarg422.txt is pulled in and that the results are consistent. -Will From strange at nsk.no-ip.org Fri May 28 13:52:59 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 28 May 2004 14:52:59 +0100 Subject: gnome-terminal benchmark In-Reply-To: <40B73BA2.4010707@redhat.com> References: <40B64DD2.6080508@redhat.com> <20040528101939.GA11833@nsk.no-ip.org> <40B73BA2.4010707@redhat.com> Message-ID: <20040528135258.GA18201@nsk.no-ip.org> On Fri, May 28, 2004 at 09:16:18AM -0400, Will Cohen wrote: > Luciano Miguel Ferreira Rocha wrote: > >On Thu, May 27, 2004 at 04:21:38PM -0400, Will Cohen wrote: > > > >># The actual benchmark being timed is below. > >>/usr/bin/time /bin/cat `pwd`/jarg422.txt 2>> $RESULTS_FILE > > > > > >You're profiling cat under gnome-terminal, not gnome-terminal + cat. > > > >Wouldn't be better to run instead: > >/usr/bin/time gnome-terminal -x cat $PWD/jarg422.txt > > You are correct that this also includes the time for the cat. I tried > that earlier there are comments on that in the procedure. I have no problem with cat being included in the calculated time. It shouldn't consume much. > The net result > with the suggested change on gnome-terminal is that you get the amount > of time it takes to fire off the command to the gnome-terminal server, > not the amount of time to complete the task. The /usr/bin/time will > finish long before the cat is actually done. Oh, yes, I forgot. I usually run gnome-terminal with the options --disable-factory --sm-disable. They should prevent the use of a gnome-terminal server, giving more meaningful results. > Doing something like that > on xterm you will get gnome-terminal + cat time. > > The goal of the benchmark was to make something that could provide some > indication about the amount of time required to push a lot of text to a > terminal window, exercise some of the gnome-terminal code, be reasonably > easy to run, and have some chance at being repeatable. That the > exeperiment includes time for cat is not that big an issue, so long the > amount of time for cat stays the same and cat times don't totally > dominate the time. If you have oprofile setup and run the benchmark with > "--profile" you can see that xterm dominates the cpu by a large margin, > about 75% of the samples. I wasn't sure about oprofile also recording other applications. Guess I should read a good documentation about it. Regards, Luciano Rocha From otaylor at redhat.com Fri May 28 18:19:42 2004 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 28 May 2004 14:19:42 -0400 Subject: gnome-terminal benchmark In-Reply-To: <20040528135258.GA18201@nsk.no-ip.org> References: <40B64DD2.6080508@redhat.com> <20040528101939.GA11833@nsk.no-ip.org> <40B73BA2.4010707@redhat.com> <20040528135258.GA18201@nsk.no-ip.org> Message-ID: <1085768381.27604.29.camel@localhost.localdomain> On Fri, 2004-05-28 at 09:52, Luciano Miguel Ferreira Rocha wrote: > > The net result > > with the suggested change on gnome-terminal is that you get the amount > > of time it takes to fire off the command to the gnome-terminal server, > > not the amount of time to complete the task. The /usr/bin/time will > > finish long before the cat is actually done. > > Oh, yes, I forgot. I usually run gnome-terminal with the options > --disable-factory --sm-disable. They should prevent the use of a > gnome-terminal server, giving more meaningful results. But is it interesting to time the startup time of gnome-terminal? While that's perhaps an interesting benchmark as well, it has little correlation with questions like "how fast will my kernel compile go when run in gnome-terminal"? If we are measuring wall clock time, timing the cat command seems to be pretty appropriate. If we are measuring CPU usage, then we need to find CPU usage from the terminal *and* from the X server, so we already need to use a tool like oprofile that can get a global view. Regards, Owen -------------- 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 strange at nsk.no-ip.org Fri May 28 20:17:09 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 28 May 2004 21:17:09 +0100 Subject: gnome-terminal benchmark In-Reply-To: <1085768381.27604.29.camel@localhost.localdomain> References: <40B64DD2.6080508@redhat.com> <20040528101939.GA11833@nsk.no-ip.org> <40B73BA2.4010707@redhat.com> <20040528135258.GA18201@nsk.no-ip.org> <1085768381.27604.29.camel@localhost.localdomain> Message-ID: <20040528201709.GB29722@nsk.no-ip.org> On Fri, May 28, 2004 at 02:19:42PM -0400, Owen Taylor wrote: > But is it interesting to time the startup time of gnome-terminal? While > that's perhaps an interesting benchmark as well, it has little > correlation with questions like "how fast will my kernel compile > go when run in gnome-terminal"? But will cat end after all output has been displayed or before? (Due to pipe buffers.) > If we are measuring wall clock time, timing the cat command seems > to be pretty appropriate. > > If we are measuring CPU usage, then we need to find CPU usage from > the terminal *and* from the X server, so we already need to use a > tool like oprofile that can get a global view. I agree. Regards, Luciano Rocha -- Consciousness: that annoying time between naps. From wcohen at redhat.com Fri May 28 20:24:42 2004 From: wcohen at redhat.com (Will Cohen) Date: Fri, 28 May 2004 16:24:42 -0400 Subject: gnome-terminal benchmark In-Reply-To: <20040528201709.GB29722@nsk.no-ip.org> References: <40B64DD2.6080508@redhat.com> <20040528101939.GA11833@nsk.no-ip.org> <40B73BA2.4010707@redhat.com> <20040528135258.GA18201@nsk.no-ip.org> <1085768381.27604.29.camel@localhost.localdomain> <20040528201709.GB29722@nsk.no-ip.org> Message-ID: <40B7A00A.9090603@redhat.com> Luciano Miguel Ferreira Rocha wrote: > On Fri, May 28, 2004 at 02:19:42PM -0400, Owen Taylor wrote: > >>But is it interesting to time the startup time of gnome-terminal? While >>that's perhaps an interesting benchmark as well, it has little >>correlation with questions like "how fast will my kernel compile >>go when run in gnome-terminal"? > > > But will cat end after all output has been displayed or before? (Due to > pipe buffers.) I don't know. That is a good question. I don't know enough about the gnome-terminal internals to say. >>If we are measuring wall clock time, timing the cat command seems >>to be pretty appropriate. >> >>If we are measuring CPU usage, then we need to find CPU usage from >>the terminal *and* from the X server, so we already need to use a >>tool like oprofile that can get a global view. > > > I agree. > > Regards, > Luciano Rocha > From wcohen at redhat.com Fri May 28 20:39:30 2004 From: wcohen at redhat.com (Will Cohen) Date: Fri, 28 May 2004 16:39:30 -0400 Subject: Desktop application start up indicators Message-ID: <40B7A382.6010809@redhat.com> I am thinking about ways to measure the startup time for various desktop applications. Obviously, a common one used is how soon after a menu item is selected can I do something in the application. However, this does not lend itself to being automated. I assume that most of the applications can be launched from a command line. Are there applications or applets that are started from the menu and do not have corresponding command line invocations? How similar are the gnome applications in startup? Do they use the same set of libraries? Would it be possible to have instrument a function in a common shared library that generally indicates that the application has initialized everything and is just waiting for the user to do something? If there is a common function could do something like: start profiling note time command-line invocation of application -Will From hp at redhat.com Fri May 28 22:02:26 2004 From: hp at redhat.com (Havoc Pennington) Date: Fri, 28 May 2004 18:02:26 -0400 Subject: Desktop application start up indicators In-Reply-To: <40B7A382.6010809@redhat.com> References: <40B7A382.6010809@redhat.com> Message-ID: <1085781746.7515.79.camel@localhost.localdomain> On Fri, 2004-05-28 at 16:39, Will Cohen wrote: > start profiling > note time > command-line invocation of application > > > You could just profile this program: int main (int argc, char **argv) { gtk_init (&argc, &argv); exit (0); } The equivalent for GNOME is a bit more complex (and probably wastes a fair bit more time). It's probably a better measure if you create a window, rather than just the init, since some things are done lazily: int main (int argc, char **argv) { GtkWidget *window; GtkWidget *button; gtk_init (&argc, &argv); window = gtk_window_new (GTK_WINDOW_TOPLEVEL); button = gtk_button_new_with_label ("Hello"); gtk_container_add (GTK_CONTAINER (window), button); gtk_widget_show (button); gtk_widget_show_now (window); /* blocks in mainloop until window has been mapped by X server */ exit (0); } That should be a good measure of how long it takes GTK + X server to get a minimal window on the screen. One thing we know takes time is loading stock icons, so you could make the button have an icon to add profiling of that issue: gtk_button_new_from_stock (GTK_STOCK_OPEN); Havoc From markmc at redhat.com Sun May 30 09:21:19 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Sun, 30 May 2004 10:21:19 +0100 Subject: Desktop application start up indicators In-Reply-To: <40B7A382.6010809@redhat.com> References: <40B7A382.6010809@redhat.com> Message-ID: <1085908878.8132.8.camel@localhost.localdomain> Hi Will, On Fri, 2004-05-28 at 21:39, Will Cohen wrote: > I am thinking about ways to measure the startup time for various desktop > applications. Obviously, a common one used is how soon after a menu item > is selected can I do something in the application. However, this does > not lend itself to being automated. > > I assume that most of the applications can be launched from a command > line. Are there applications or applets that are started from the menu > and do not have corresponding command line invocations? > > How similar are the gnome applications in startup? Do they use the same > set of libraries? Would it be possible to have instrument a function in > a common shared library that generally indicates that the application > has initialized everything and is just waiting for the user to do > something? I'm not sure there is a reliable way to detect when an application has finished startup. Perhaps the first time the main loop goes idle would be a good indicator but I think you have difficulty distinguishing between that case and the case of the app blocking on the result of a CORBA call. To give you an idea of where a GNOME application starting up spends its time see this: http://mail.gnome.org/archives/desktop-devel-list/2004-April/msg00360.html The only things really specific to the panel in this is the loading of main menu and applets/launchers. Cheers, Mark. From otaylor at redhat.com Sun May 30 14:45:57 2004 From: otaylor at redhat.com (Owen Taylor) Date: Sun, 30 May 2004 10:45:57 -0400 Subject: Desktop application start up indicators In-Reply-To: <1085908878.8132.8.camel@localhost.localdomain> References: <40B7A382.6010809@redhat.com> <1085908878.8132.8.camel@localhost.localdomain> Message-ID: <1085928357.29803.3.camel@localhost.localdomain> On Sun, 2004-05-30 at 05:21, Mark McLoughlin wrote: > > I'm not sure there is a reliable way to detect when an application has > finished startup. Perhaps the first time the main loop goes idle would > be a good indicator but I think you have difficulty distinguishing > between that case and the case of the app blocking on the result of a > CORBA call. For nmany applications, a pretty good good (intrusive) way to figure out when the app is up on the screen and painted is to put a g_idle_add() into an expose handler; applications will typically handle all exposes before going idle again. > To give you an idea of where a GNOME application starting up spends its > time see this: > > http://mail.gnome.org/archives/desktop-devel-list/2004-April/msg00360.html > > The only things really specific to the panel in this is the loading of > main menu and applets/launchers. I believe this is 'strace -tt' measurement? My experience is that that can be quite distorting because it greatly magnifies the per-syscall overhead. Regards, Owen -------------- 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 markmc at redhat.com Sun May 30 16:08:27 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Sun, 30 May 2004 17:08:27 +0100 Subject: Desktop application start up indicators In-Reply-To: <1085928357.29803.3.camel@localhost.localdomain> References: <40B7A382.6010809@redhat.com> <1085908878.8132.8.camel@localhost.localdomain> <1085928357.29803.3.camel@localhost.localdomain> Message-ID: <1085933307.1745.5.camel@localhost.localdomain> Hi Owen, On Sun, 2004-05-30 at 15:45, Owen Taylor wrote: > On Sun, 2004-05-30 at 05:21, Mark McLoughlin wrote: > > To give you an idea of where a GNOME application starting up spends its > > time see this: > > > > http://mail.gnome.org/archives/desktop-devel-list/2004-April/msg00360.html > > > > The only things really specific to the panel in this is the loading of > > main menu and applets/launchers. > > I believe this is 'strace -tt' measurement? My experience is that that > can be quite distorting because it greatly magnifies the per-syscall > overhead. Yeah, you mentioned :/ I only thought it would be of interest to Will as "here's the types of things GNOME apps are doing on startup" rather than "here's how a GNOME apps startup time is split". I'd really love a way of doing this kind of a wall-clock breakdown of application startup time *without* such distortion ... Cheers, Mark. From ian at sskatings.demon.co.uk Sun May 30 17:16:24 2004 From: ian at sskatings.demon.co.uk (Ian Robertson) Date: Sun, 30 May 2004 18:16:24 +0100 Subject: Running Applix 5 on Fedora Message-ID: <1085937384.1084.3.camel@sskatings.demon.co.uk> Hello I have just loaded Fedora onto one of my systems and have tried to load Applix. The install process kept falling over but I managed to force each individual rpm onto the system. However when I try to load I get this message: [ian at sskatings2 ian]$ /opt/applix/axdata/axmain: relocation error: /usr/lib/libgdk-1.2.so.0: undefined symbol: XShmQueryVersion axnet error, axmain already started. /opt/applix/axdata/axmain: relocation error: /usr/lib/libgdk-1.2.so.0: undefined symbol: XShmQueryVersion Ayone any suggestions please as i do like this software and hope to run it for some time yet Regards Ian -- Ian Robertson Tel +44 (0)1224 624811 Tel/Fax +44 (0)1224 781326 From hp at redhat.com Sun May 30 21:14:32 2004 From: hp at redhat.com (Havoc Pennington) Date: Sun, 30 May 2004 17:14:32 -0400 Subject: sound subsystem Message-ID: <1085951610.21727.114.camel@localhost.localdomain> Hi, Arjan asks that we move everything to use libasound rather than esound or OSS. Because ALSA lets multiple apps output sound at once, esound isn't really needed; the only functionality we lose is that remote apps can't play sound on the local system, but that functionality was pretty hosed with esound anyway. I don't have a sense of how many things are accessing OSS/esound directly, or how much work is involved here. Havoc From notting at redhat.com Mon May 31 03:36:27 2004 From: notting at redhat.com (Bill Nottingham) Date: Sun, 30 May 2004 23:36:27 -0400 Subject: sound subsystem In-Reply-To: <1085951610.21727.114.camel@localhost.localdomain> References: <1085951610.21727.114.camel@localhost.localdomain> Message-ID: <20040531033627.GB26730@nostromo.devel.redhat.com> Havoc Pennington (hp at redhat.com) said: > Arjan asks that we move everything to use libasound rather than esound > or OSS. Because ALSA lets multiple apps output sound at once, esound > isn't really needed; the only functionality we lose is that remote apps > can't play sound on the local system, but that functionality was pretty > hosed with esound anyway. Well.... ALSA by default only lets multiple apps output *up to the number of HW channels the card has*. Doing more requires configuration. Bill From hp at redhat.com Mon May 31 19:03:53 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 31 May 2004 15:03:53 -0400 Subject: sound subsystem In-Reply-To: <20040531033627.GB26730@nostromo.devel.redhat.com> References: <1085951610.21727.114.camel@localhost.localdomain> <20040531033627.GB26730@nostromo.devel.redhat.com> Message-ID: <1086030233.21727.132.camel@localhost.localdomain> On Sun, 2004-05-30 at 23:36, Bill Nottingham wrote: > Well.... ALSA by default only lets multiple apps output *up to the > number of HW channels the card has*. I've been told that all interesting cards have at least 2 channels (maybe more?) > Doing more requires configuration. Configuration we can do by default? Havoc From behdad at cs.toronto.edu Mon May 31 19:10:56 2004 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 31 May 2004 15:10:56 -0400 Subject: sound subsystem In-Reply-To: <1086030233.21727.132.camel@localhost.localdomain> References: <1085951610.21727.114.camel@localhost.localdomain> <20040531033627.GB26730@nostromo.devel.redhat.com> <1086030233.21727.132.camel@localhost.localdomain> Message-ID: On Mon, 31 May 2004, Havoc Pennington wrote: > On Sun, 2004-05-30 at 23:36, Bill Nottingham wrote: > > Well.... ALSA by default only lets multiple apps output *up to the > > number of HW channels the card has*. > > I've been told that all interesting cards have at least 2 channels > (maybe more?) Guess that needs configuration too. Right now I'm using ALSA on my laptop, don't know how many channels, but only one application can play, and the other sounds are *queued* until the current one stops. > > Doing more requires configuration. > > Configuration we can do by default? A couple of months back I configured an ALSA mixer, but after a few seconds of playback, it used to get stuck for no reason. Of course it may have been fixed by now. And oh, it needs applications being configured to use that software mixer device instead of default ALSA device for playback (xmms, gaim, etc). > Havoc --behdad behdad.org From mdraghi at prosud.com Mon May 31 19:36:32 2004 From: mdraghi at prosud.com (Mariano Draghi) Date: Mon, 31 May 2004 16:36:32 -0300 Subject: sound subsystem In-Reply-To: References: <1085951610.21727.114.camel@localhost.localdomain> <20040531033627.GB26730@nostromo.devel.redhat.com> <1086030233.21727.132.camel@localhost.localdomain> Message-ID: Behdad Esfahbod escribi?: > > A couple of months back I configured an ALSA mixer, but after a > few seconds of playback, it used to get stuck for no reason. Of > course it may have been fixed by now. I'm using software mixing w/ALSA here. Haven't tested it that much, but so far so good. And it takes only a ~/.asoundrc file. > And oh, it needs > applications being configured to use that software mixer device > instead of default ALSA device for playback (xmms, gaim, etc). Well, someone posted a few days ago a tip on the fedora-list on how to make the software input & output devices the default. That's the one I'm using, and as long the applications are configured to use ALSA, they end using the sw mixing. I tested it w/ XMMS, Xine and the system sounds in Gnome, it works and I didn't have to tweak anything but just the ~/.asoundrc. I don't have this thread off hand, but I guess if you search the fedora-list it will pop up. I think it's a nice default to include... but it needs more testing, though. f.i., I don't know if there's any performance hit by doing this (I suppose there is) Regards, -- Mariano From mdraghi at prosud.com Mon May 31 19:52:22 2004 From: mdraghi at prosud.com (Mariano Draghi) Date: Mon, 31 May 2004 16:52:22 -0300 Subject: sound subsystem In-Reply-To: References: <1085951610.21727.114.camel@localhost.localdomain> <20040531033627.GB26730@nostromo.devel.redhat.com> <1086030233.21727.132.camel@localhost.localdomain> Message-ID: Mariano Draghi escribi?: > Behdad Esfahbod escribi?: (...) >> And oh, it needs >> applications being configured to use that software mixer device >> instead of default ALSA device for playback (xmms, gaim, etc). > > Well, someone posted a few days ago a tip on the fedora-list on how to > make the software input & output devices the default. Here, this is the thread: http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00989.html (it was on the devel-list) I'm using exactlty that .asoundrc -- Mariano From hp at redhat.com Mon May 31 20:31:43 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 31 May 2004 16:31:43 -0400 Subject: sound subsystem In-Reply-To: References: <1085951610.21727.114.camel@localhost.localdomain> <20040531033627.GB26730@nostromo.devel.redhat.com> <1086030233.21727.132.camel@localhost.localdomain> Message-ID: <1086035503.21727.158.camel@localhost.localdomain> On Mon, 2004-05-31 at 15:36, Mariano Draghi wrote: > I'm using software mixing w/ALSA here. Haven't tested it that much, but > so far so good. > And it takes only a ~/.asoundrc file. Ah geez, there's a .asoundrc... and the file format looks like some made-up custom hack... grumble. ;-) Hopefully not an indication that someone is punting things that should just work onto the end user. > Well, someone posted a few days ago a tip on the fedora-list on how to > make the software input & output devices the default. > That's the one I'm using, and as long the applications are configured to > use ALSA, they end using the sw mixing. I tested it w/ XMMS, Xine and > the system sounds in Gnome, it works and I didn't have to tweak anything > but just the ~/.asoundrc. We really have to make the default whatever _works_, end user configuration requirements in this area are pretty much unacceptable... if software mixing is the only way to get mixing 100% of the time, and we want to avoid the software mixing when hardware mixing is possible, alsa will just have to be smart enough to auto-determine when hardware mixing is possible and automatically fall back to software otherwise. Or some other sane automatic policy. In the meantime can we just pop the systemwide default over to software mixing? Havoc