From jkeating at redhat.com Thu Jul 10 13:44:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 10 Jul 2008 09:44:21 -0400 Subject: Unexpected shutdown... what? Message-ID: <1215697461.8454.1.camel@localhost.localdomain> Every single time I log out of gnome or shut down / reboot from the gnome menu a few of my apps act as if they were kill -9'd and throw up recovery messages that frighten/confuse users. Why? Why can't we as we log out/shut down 'cleanly' close these applications? Why must everything be 'dirty' upon login? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Thu Jul 10 13:53:47 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 10 Jul 2008 09:53:47 -0400 Subject: Unexpected shutdown... what? In-Reply-To: <1215697461.8454.1.camel@localhost.localdomain> References: <1215697461.8454.1.camel@localhost.localdomain> Message-ID: <1215698027.3290.3.camel@localhost.localdomain> On Thu, 2008-07-10 at 09:44 -0400, Jesse Keating wrote: > Every single time I log out of gnome or shut down / reboot from the > gnome menu a few of my apps act as if they were kill -9'd and throw up > recovery messages that frighten/confuse users. Why? Why can't we as we > log out/shut down 'cleanly' close these applications? Why must > everything be 'dirty' upon login? Session management is in a somewhat broken state right now. I've sent my emissaries to Guadec to sort things out... From kmaraas at broadpark.no Sun Jul 13 11:41:45 2008 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Sun, 13 Jul 2008 13:41:45 +0200 Subject: Unexpected shutdown... what? In-Reply-To: <1215698027.3290.3.camel@localhost.localdomain> References: <1215697461.8454.1.camel@localhost.localdomain> <1215698027.3290.3.camel@localhost.localdomain> Message-ID: <1215949305.6232.3.camel@localhost.localdomain> to., 10.07.2008 kl. 09.53 -0400, skrev Matthias Clasen: > On Thu, 2008-07-10 at 09:44 -0400, Jesse Keating wrote: > > Every single time I log out of gnome or shut down / reboot from the > > gnome menu a few of my apps act as if they were kill -9'd and throw up > > recovery messages that frighten/confuse users. Why? Why can't we as we > > log out/shut down 'cleanly' close these applications? Why must > > everything be 'dirty' upon login? > > Session management is in a somewhat broken state right now. > I've sent my emissaries to Guadec to sort things out... > Is this also the reason why I can't see the reboot and shut down buttons when I choose System->Shut down? The dialog that opens just has Hibernate, Suspend and Cancel buttons. Cheers Kjartan From maillist at diffingo.com Sun Jul 13 16:51:12 2008 From: maillist at diffingo.com (Stewart Adam) Date: Sun, 13 Jul 2008 12:51:12 -0400 Subject: Unexpected shutdown... what? In-Reply-To: <1215949305.6232.3.camel@localhost.localdomain> References: <1215697461.8454.1.camel@localhost.localdomain> <1215698027.3290.3.camel@localhost.localdomain> <1215949305.6232.3.camel@localhost.localdomain> Message-ID: <1215967872.3703.7.camel@Diffingo.localdomain> On Sun, 2008-07-13 at 13:41 +0200, Kjartan Maraas wrote: > Is this also the reason why I can't see the reboot and shut down buttons > when I choose System->Shut down? > > The dialog that opens just has Hibernate, Suspend and Cancel buttons. > > Cheers > Kjartan > I see that too, my workaround has been to logout then click "Shutdown" in GDM... Stewart From mclasen at redhat.com Mon Jul 14 14:27:14 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 14 Jul 2008 10:27:14 -0400 Subject: Unexpected shutdown... what? In-Reply-To: <1215949305.6232.3.camel@localhost.localdomain> References: <1215697461.8454.1.camel@localhost.localdomain> <1215698027.3290.3.camel@localhost.localdomain> <1215949305.6232.3.camel@localhost.localdomain> Message-ID: <1216045634.3259.0.camel@localhost.localdomain> On Sun, 2008-07-13 at 13:41 +0200, Kjartan Maraas wrote: > to., 10.07.2008 kl. 09.53 -0400, skrev Matthias Clasen: > > On Thu, 2008-07-10 at 09:44 -0400, Jesse Keating wrote: > > > Every single time I log out of gnome or shut down / reboot from the > > > gnome menu a few of my apps act as if they were kill -9'd and throw up > > > recovery messages that frighten/confuse users. Why? Why can't we as we > > > log out/shut down 'cleanly' close these applications? Why must > > > everything be 'dirty' upon login? > > > > Session management is in a somewhat broken state right now. > > I've sent my emissaries to Guadec to sort things out... > > > Is this also the reason why I can't see the reboot and shut down buttons > when I choose System->Shut down? > > The dialog that opens just has Hibernate, Suspend and Cancel buttons. Yes, same reason. From jkeating at redhat.com Mon Jul 14 14:51:03 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Jul 2008 10:51:03 -0400 Subject: Slowness getting back on network from resume Message-ID: <1216047063.3438.11.camel@localhost.localdomain> This likely isn't any desktop component that is causing this, but I'd like to know what it is that makes getting back on wireless network after resuming from suspend take so long. I've bee comparing with Vista on my laptop just for giggles, and Vista is back on the wireless and FF even refreshes my gmail before I can get my password typed into the screen lock. This is all very very very fast. F9 on the other hand takes longer to get to the password dialog and then once unlocked it can still be another minute+ before NM starts the connection dance, another 30 seconds after that before wireless picks up again. Where is the delay? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Mon Jul 14 14:52:16 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 14 Jul 2008 10:52:16 -0400 Subject: Slowness getting back on network from resume In-Reply-To: <1216047063.3438.11.camel@localhost.localdomain> References: <1216047063.3438.11.camel@localhost.localdomain> Message-ID: <1216047136.22834.6.camel@rosebud> On Mon, 2008-07-14 at 10:51 -0400, Jesse Keating wrote: > This likely isn't any desktop component that is causing this, but I'd > like to know what it is that makes getting back on wireless network > after resuming from suspend take so long. I've bee comparing with Vista > on my laptop just for giggles, and Vista is back on the wireless and FF > even refreshes my gmail before I can get my password typed into the > screen lock. This is all very very very fast. F9 on the other hand > takes longer to get to the password dialog and then once unlocked it can > still be another minute+ before NM starts the connection dance, another > 30 seconds after that before wireless picks up again. Where is the > delay? > Which card and which kernel? I noticed really slow to never pick up times on the iwl4965 on -86 kernel. -sv From jkeating at redhat.com Mon Jul 14 15:00:03 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Jul 2008 11:00:03 -0400 Subject: Slowness getting back on network from resume In-Reply-To: <1216047136.22834.6.camel@rosebud> References: <1216047063.3438.11.camel@localhost.localdomain> <1216047136.22834.6.camel@rosebud> Message-ID: <1216047603.3438.13.camel@localhost.localdomain> On Mon, 2008-07-14 at 10:52 -0400, seth vidal wrote: > > Which card and which kernel? I noticed really slow to never pick up > times on the iwl4965 on -86 kernel. 4965, any kernel I've thrown at it that actually has working wireless drivers. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Mon Jul 14 14:59:36 2008 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 14 Jul 2008 10:59:36 -0400 Subject: Slowness getting back on network from resume In-Reply-To: <1216047136.22834.6.camel@rosebud> References: <1216047063.3438.11.camel@localhost.localdomain> <1216047136.22834.6.camel@rosebud> Message-ID: <1216047576.24527.100.camel@victoria> On Mon, 2008-07-14 at 10:52 -0400, seth vidal wrote: > On Mon, 2008-07-14 at 10:51 -0400, Jesse Keating wrote: > > This likely isn't any desktop component that is causing this, but I'd > > like to know what it is that makes getting back on wireless network > > after resuming from suspend take so long. I've bee comparing with Vista > > on my laptop just for giggles, and Vista is back on the wireless and FF > > even refreshes my gmail before I can get my password typed into the > > screen lock. This is all very very very fast. F9 on the other hand > > takes longer to get to the password dialog and then once unlocked it can > > still be another minute+ before NM starts the connection dance, another > > 30 seconds after that before wireless picks up again. Where is the > > delay? > > > > Which card and which kernel? I noticed really slow to never pick up > times on the iwl4965 on -86 kernel. Same result here, 2.6.25.9-76.fc9 and iwl3945. . -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 notting at redhat.com Mon Jul 14 15:08:48 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 Jul 2008 11:08:48 -0400 Subject: Slowness getting back on network from resume In-Reply-To: <1216047063.3438.11.camel@localhost.localdomain> References: <1216047063.3438.11.camel@localhost.localdomain> Message-ID: <20080714150848.GB7544@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > This likely isn't any desktop component that is causing this, but I'd > like to know what it is that makes getting back on wireless network > after resuming from suspend take so long. I've bee comparing with Vista > on my laptop just for giggles, and Vista is back on the wireless and FF > even refreshes my gmail before I can get my password typed into the > screen lock. This is all very very very fast. F9 on the other hand > takes longer to get to the password dialog and then once unlocked it can > still be another minute+ before NM starts the connection dance, another > 30 seconds after that before wireless picks up again. Where is the > delay? Is Windows caching the IP & scan information across suspend/resume? Bill From jkeating at redhat.com Mon Jul 14 19:07:14 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Jul 2008 15:07:14 -0400 Subject: Slowness getting back on network from resume In-Reply-To: <20080714150848.GB7544@nostromo.devel.redhat.com> References: <1216047063.3438.11.camel@localhost.localdomain> <20080714150848.GB7544@nostromo.devel.redhat.com> Message-ID: <1216062434.3631.9.camel@localhost.localdomain> On Mon, 2008-07-14 at 11:08 -0400, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > This likely isn't any desktop component that is causing this, but I'd > > like to know what it is that makes getting back on wireless network > > after resuming from suspend take so long. I've bee comparing with Vista > > on my laptop just for giggles, and Vista is back on the wireless and FF > > even refreshes my gmail before I can get my password typed into the > > screen lock. This is all very very very fast. F9 on the other hand > > takes longer to get to the password dialog and then once unlocked it can > > still be another minute+ before NM starts the connection dance, another > > 30 seconds after that before wireless picks up again. Where is the > > delay? > > Is Windows caching the IP & scan information across suspend/resume? > > Bill It's entirely possible. It seems awfully fast. I haven't yet tried moving to a different area / access point between suspends to see how it handles that. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jonstanley at gmail.com Mon Jul 14 19:47:34 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 14 Jul 2008 15:47:34 -0400 Subject: Slowness getting back on network from resume In-Reply-To: <20080714150848.GB7544@nostromo.devel.redhat.com> References: <1216047063.3438.11.camel@localhost.localdomain> <20080714150848.GB7544@nostromo.devel.redhat.com> Message-ID: On Mon, Jul 14, 2008 at 11:08 AM, Bill Nottingham wrote: > Is Windows caching the IP & scan information across suspend/resume? I'm required to use a Windows laptop for $DAYJOB, and I noticed the same, fast, behavior when going from the office (wired network) to wireless at home. I've not done any actual speed comparisons, nor can I do so today (working from home due to my bum shoulder for awhile....) I also notice my Windows machine can be slow as a dog, thrashing the hard disk, and I have no tools to diagnose that like I would on Fedora (my first guess is the stupid antivirus). You win some, you lose some :) From dcbw at redhat.com Tue Jul 15 15:40:25 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 15 Jul 2008 11:40:25 -0400 Subject: Slowness getting back on network from resume In-Reply-To: <1216047063.3438.11.camel@localhost.localdomain> References: <1216047063.3438.11.camel@localhost.localdomain> Message-ID: <1216136425.6039.44.camel@localhost.localdomain> On Mon, 2008-07-14 at 10:51 -0400, Jesse Keating wrote: > This likely isn't any desktop component that is causing this, but I'd > like to know what it is that makes getting back on wireless network > after resuming from suspend take so long. I've bee comparing with Vista > on my laptop just for giggles, and Vista is back on the wireless and FF > even refreshes my gmail before I can get my password typed into the > screen lock. This is all very very very fast. F9 on the other hand > takes longer to get to the password dialog and then once unlocked it can > still be another minute+ before NM starts the connection dance, another > 30 seconds after that before wireless picks up again. Where is the > delay? NM throws away the current access point list on suspend/hibernate. On resume from sleep/hibernate, it needs to do a scan or two to find the network to associate with, and after that, do the whole connection process (including DHCP) again. There is a considerable amount of lag here, and there's certainly room for improvement. First, we need better kernel interfaces for wireless. Finishing nl80211/cfg80211 and ensuring that they have a more request/response oriented API [1] is the way to go. Second, Mac OS X and Windows indicate connection differently from NetworkManager. Mac OS X will show that Airport is "connected" way before it's successfully completed DHCP or IP assignment. That's a completely useless status since you can't actually do anything in that state, so NetworkManager considers the "connected" state to be once all IP configuration is complete and successful. Third, drivers still suck for scanning. Ideally, we'd just fire off a quick scan right after NM wakes back up, get back a nice list of access points, and immediately connect to one of them. For whatever reason a single scan is still not reliable enough to get an adequate picture of the network around you. And since scans can take quite a bit of time to complete [2] you get unacceptable latency here. So how to fix this? a) Get drivers to support specific SSID scanning (unfortunately older drivers probably won't be able to do this, but all mac80211 drivers can), and when an SSID scan is requested, make that jump to the start of the scan queue. Have the driver/mac80211 provide a specific response to that scan request so that NetworkManager knows the result. b) When coming out of sleep, have NetworkManager SSID scan the last connected AP. If that AP doesn't show up in scan results (its not there, the driver sucks, etc), continue as normal. If that AP does show up in scan results, try to associate with that AP. c) Since NM controls the DHCP client, NM is capable of providing different lease files to dhclient for each network you've connected to. So for 'my-home-wireless' NM could try to re-acquire the previous lease before falling back to a complete DHCP transaction. I don't really know how much time this would save, since lots of the latency is in the wpa_supplicant <-> driver communication during authentication/association because the WEXT API is so bad at reporting it's status. But that can be improved independently of the NM bits, and the stuff above is definitely a win. Try resuming while plugged into a cable, and NM will be REALLY FAST. It's just when you throw wireless into the mix that stuff gets more complicated and therefore quite a bit laggier. Dan [1] i.e. a way to track the result of specific requests. With WEXT you say "associate to X" and some time later the driver may or may not send association status back, but there's no ID/cookie to tie that result back to the original request that was made. Would be nice to be able to track the progress of asynchronous operations through the driver/kernel. [2] historically up to 10s with madwifi to scan both A and B/G bands; you have up to 60 channels with at least a 100ms passive scan dwell time on each channel, and maybe 50ms channel switch lag, not including firmware/driver command latency. SSID scanning (called an "active scan" in 802.11) helps because you send out the probe request and only have to wait 20 or 30ms before giving up, instead of the minimum 100ms a passive scan requires. From jkeating at redhat.com Tue Jul 15 16:02:59 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Jul 2008 12:02:59 -0400 Subject: Slowness getting back on network from resume In-Reply-To: <1216136425.6039.44.camel@localhost.localdomain> References: <1216047063.3438.11.camel@localhost.localdomain> <1216136425.6039.44.camel@localhost.localdomain> Message-ID: <1216137779.3631.197.camel@localhost.localdomain> On Tue, 2008-07-15 at 11:40 -0400, Dan Williams wrote: > > Second, Mac OS X and Windows indicate connection differently from > NetworkManager. Mac OS X will show that Airport is "connected" way > before it's successfully completed DHCP or IP assignment. That's a > completely useless status since you can't actually do anything in that > state, so NetworkManager considers the "connected" state to be once all > IP configuration is complete and successful. I wouldn't lump Windows in here necessarily. As I stated in my mail that by the time I clear the screen lock, not only is the wireless connected, but it's actually communicating with the Internet, enough to get my gmail refreshed. The rest of the info is good, this feels like fit/polish that could go a long way either for the good, or if left along go a long way for the bad. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From wwoods at redhat.com Thu Jul 17 17:43:28 2008 From: wwoods at redhat.com (Will Woods) Date: Thu, 17 Jul 2008 13:43:28 -0400 Subject: Patch: timed progressbar for plymouth-plugin-spinfinity Message-ID: <1216316608.31373.59.camel@metroid.rdu.redhat.com> Hi, This proof-of-concept patch adds a simple progress bar to plymouth's "Spinfinity" plugin. The progress bar uses an estimate of boot time - defaulting to 45 seconds if unknown - and runs from 0% to 100% over that interval. Furthermore, the patch measures how long it takes to boot and writes that value to /etc/boottime at plugin shutdown. (This is kind of a nice side-effect - we get actual *measured* boot speed data, rather than just "feels snappier!") There's an associated script, update-boottime, that crams /etc/boottime into your initrd, so this splash plugin can use *that* to more closely approximate the time required to boot. This is similar to the OS X "WaitingForLoginWindow" process. It's an effective placebo - startup *seems* faster with the progress bar, even though it's exactly the same. You can enable it by adding 'timebar:1' to the boot commandline. This will make it run in linear-time mode - the progress bar moves linearly from 0% to 100%. Using 'timebar:2' modifies the percentage calculation to use an exponential function - this makes the bar run faster at first, then slow as it approaches 100%. This makes startup seem even faster. Seriously! The bar (and its implementation) are kind of ugly right now, but again - this is just a proof-of-concept. I think people get impatient with spinners after ~15s or so, so I think it's probably worth the effort to add something like this. Don't underestimate the *perceived* difference in startup speed - or at least the feeling that it's actually Doing Something during those ~40-50 seconds it takes system(s) to start. Try it yourself. See if you think it makes a difference. If people ask, I'll generate some binary packages of the 'timebar' plugin for people to test out, but I wanted to give you all a look at the code (and a chance to discuss the concept) first. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: update-boottime Type: application/x-shellscript Size: 2104 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: plymouth-0.5.0-spinfinity-timebar.patch Type: text/x-patch Size: 6746 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3153 bytes Desc: not available URL: From wwoods at redhat.com Thu Jul 17 21:30:32 2008 From: wwoods at redhat.com (Will Woods) Date: Thu, 17 Jul 2008 17:30:32 -0400 Subject: Unexpected shutdown... what? In-Reply-To: <1216045634.3259.0.camel@localhost.localdomain> References: <1215697461.8454.1.camel@localhost.localdomain> <1215698027.3290.3.camel@localhost.localdomain> <1215949305.6232.3.camel@localhost.localdomain> <1216045634.3259.0.camel@localhost.localdomain> Message-ID: <1216330232.31373.64.camel@metroid.rdu.redhat.com> On Mon, 2008-07-14 at 10:27 -0400, Matthias Clasen wrote: > On Sun, 2008-07-13 at 13:41 +0200, Kjartan Maraas wrote: > > to., 10.07.2008 kl. 09.53 -0400, skrev Matthias Clasen: > > > On Thu, 2008-07-10 at 09:44 -0400, Jesse Keating wrote: > > > > Every single time I log out of gnome or shut down / reboot from the > > > > gnome menu a few of my apps act as if they were kill -9'd and throw up > > > > recovery messages that frighten/confuse users. Why? Why can't we as we > > > > log out/shut down 'cleanly' close these applications? Why must > > > > everything be 'dirty' upon login? > > > > > > Session management is in a somewhat broken state right now. > > > I've sent my emissaries to Guadec to sort things out... > > > > > Is this also the reason why I can't see the reboot and shut down buttons > > when I choose System->Shut down? > > > > The dialog that opens just has Hibernate, Suspend and Cancel buttons. > > Yes, same reason. There's a bug filed about it: https://bugzilla.redhat.com/show_bug.cgi?id=452639 Matthias, could you look at that bug and see if it's filed in the right place (it's currently against gnome-panel), and (if possible) give an update on the status? It's something I'd like to see fixed for F10Alpha.. Thanks! -w -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3153 bytes Desc: not available URL: From bnocera at redhat.com Thu Jul 17 22:26:21 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 17 Jul 2008 23:26:21 +0100 Subject: Patch: timed progressbar for plymouth-plugin-spinfinity In-Reply-To: <1216316608.31373.59.camel@metroid.rdu.redhat.com> References: <1216316608.31373.59.camel@metroid.rdu.redhat.com> Message-ID: <1216333581.3080.308.camel@cookie.hadess.net> On Thu, 2008-07-17 at 13:43 -0400, Will Woods wrote: > Hi, > > This proof-of-concept patch adds a simple progress bar to plymouth's > "Spinfinity" plugin. > > The progress bar uses an estimate of boot time - defaulting to 45 > seconds if unknown - and runs from 0% to 100% over that interval. > > Furthermore, the patch measures how long it takes to boot and writes > that value to /etc/boottime at plugin shutdown. Better be somewhere under /var. It's not a config option after all. > Using 'timebar:2' modifies the percentage calculation to use an > exponential function - this makes the bar run faster at first, then slow > as it approaches 100%. This makes startup seem even faster. Seriously! Awesome. Humans are so gullible. From gmureddu at prodigy.net.mx Thu Jul 17 05:12:10 2008 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Thu, 17 Jul 2008 00:12:10 -0500 Subject: Patch: timed progressbar for plymouth-plugin-spinfinity In-Reply-To: <1216333581.3080.308.camel@cookie.hadess.net> References: <1216316608.31373.59.camel@metroid.rdu.redhat.com> <1216333581.3080.308.camel@cookie.hadess.net> Message-ID: <487ED4AA.6060309@prodigy.net.mx> Bastien Nocera escribi?: >> Using 'timebar:2' modifies the percentage calculation to use an >> exponential function - this makes the bar run faster at first, then slow >> as it approaches 100%. This makes startup seem even faster. Seriously! >> > > Awesome. Humans are so gullible. > True, though I can think of ONE situation where faster boot times are desirable: laptop users. For the minute or so it takes my laptop to boot and initiate my session (no automatic session start, though), if the battery is at full 100% charge, it will eat 5% of the charge during that minute... Just do some math here and at that rate, should anything happen during boot (like the scan of the largest partition on the drive), there's only 20 or so minutes of power. From bnocera at redhat.com Fri Jul 18 06:26:04 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 18 Jul 2008 07:26:04 +0100 Subject: Patch: timed progressbar for plymouth-plugin-spinfinity In-Reply-To: <487ED4AA.6060309@prodigy.net.mx> References: <1216316608.31373.59.camel@metroid.rdu.redhat.com> <1216333581.3080.308.camel@cookie.hadess.net> <487ED4AA.6060309@prodigy.net.mx> Message-ID: <1216362364.3080.311.camel@cookie.hadess.net> On Thu, 2008-07-17 at 00:12 -0500, Gian Paolo Mureddu wrote: > Bastien Nocera escribi?: > >> Using 'timebar:2' modifies the percentage calculation to use an > >> exponential function - this makes the bar run faster at first, then slow > >> as it approaches 100%. This makes startup seem even faster. Seriously! > >> > > > > Awesome. Humans are so gullible. > > > > True, though I can think of ONE situation where faster boot times are > desirable: laptop users. For the minute or so it takes my laptop to boot > and initiate my session (no automatic session start, though), if the > battery is at full 100% charge, it will eat 5% of the charge during that > minute... Just do some math here and at that rate, should anything > happen during boot (like the scan of the largest partition on the > drive), there's only 20 or so minutes of power. I didn't say _actual_ faster boots were not desirable, just that a perceived faster boot was a good thing. FWIW, if you can only get 20 minutes of battery from your laptop, it's time to buy a new battery... From gmureddu at prodigy.net.mx Thu Jul 17 07:55:17 2008 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Thu, 17 Jul 2008 02:55:17 -0500 Subject: Patch: timed progressbar for plymouth-plugin-spinfinity In-Reply-To: <1216362364.3080.311.camel@cookie.hadess.net> References: <1216316608.31373.59.camel@metroid.rdu.redhat.com> <1216333581.3080.308.camel@cookie.hadess.net> <487ED4AA.6060309@prodigy.net.mx> <1216362364.3080.311.camel@cookie.hadess.net> Message-ID: <487EFAE5.7020203@prodigy.net.mx> Bastien Nocera escribi?: > On Thu, 2008-07-17 at 00:12 -0500, Gian Paolo Mureddu wrote: > >> Bastien Nocera escribi?: >> >>>> Using 'timebar:2' modifies the percentage calculation to use an >>>> exponential function - this makes the bar run faster at first, then slow >>>> as it approaches 100%. This makes startup seem even faster. Seriously! >>>> >>>> >>> Awesome. Humans are so gullible. >>> >>> >> True, though I can think of ONE situation where faster boot times are >> desirable: laptop users. For the minute or so it takes my laptop to boot >> and initiate my session (no automatic session start, though), if the >> battery is at full 100% charge, it will eat 5% of the charge during that >> minute... Just do some math here and at that rate, should anything >> happen during boot (like the scan of the largest partition on the >> drive), there's only 20 or so minutes of power. >> > > I didn't say _actual_ faster boots were not desirable, just that a > perceived faster boot was a good thing. FWIW, if you can only get 20 > minutes of battery from your laptop, it's time to buy a new battery... > > Well is not like I can only get 20 minutes of power out of it, is that during boot the system seems to be on an "all-on" state that draws immense amounts of power. Before all the power-saving features kick in, power drainage is very heavy. Once they're all in place I have at least 2 hours worth of battery juice. I was pointing out the immense amount of power boot up requires, at least as of F8 (I can't install F9 yet on this one due to graphics problems I experienced with a previous attempt) From davidz at redhat.com Fri Jul 18 12:12:46 2008 From: davidz at redhat.com (David Zeuthen) Date: Fri, 18 Jul 2008 08:12:46 -0400 Subject: Patch: timed progressbar for plymouth-plugin-spinfinity In-Reply-To: <1216333581.3080.308.camel@cookie.hadess.net> References: <1216316608.31373.59.camel@metroid.rdu.redhat.com> <1216333581.3080.308.camel@cookie.hadess.net> Message-ID: <1216383166.3429.7.camel@x61.fubar.dk> On Thu, 2008-07-17 at 23:26 +0100, Bastien Nocera wrote: > Better be somewhere under /var. It's not a config option after all. Actually /var/lib/plymouth or something. However - /var might be read-only so you need to gracefully handle errors - /var might be mounted pretty late in the boot process So maybe /etc isn't such a bad place after all; IIRC it's guaranteed to be on the root file system anyway. David From notting at redhat.com Fri Jul 18 12:47:29 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Jul 2008 08:47:29 -0400 Subject: Patch: timed progressbar for plymouth-plugin-spinfinity In-Reply-To: <1216383166.3429.7.camel@x61.fubar.dk> References: <1216316608.31373.59.camel@metroid.rdu.redhat.com> <1216333581.3080.308.camel@cookie.hadess.net> <1216383166.3429.7.camel@x61.fubar.dk> Message-ID: <20080718124729.GA16923@nostromo.devel.redhat.com> David Zeuthen (davidz at redhat.com) said: > On Thu, 2008-07-17 at 23:26 +0100, Bastien Nocera wrote: > > Better be somewhere under /var. It's not a config option after all. > > Actually /var/lib/plymouth or something. However > > - /var might be read-only so you need to gracefully handle errors > - /var might be mounted pretty late in the boot process > > So maybe /etc isn't such a bad place after all; IIRC it's guaranteed to > be on the root file system anyway. If /var's read-only, /etc is almost certainly read-only as well. Outside of that, once you get to the end of the plymouth run, /var will be mounted. Bill From mclasen at redhat.com Tue Jul 22 13:51:25 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 22 Jul 2008 09:51:25 -0400 Subject: new gnome-session Message-ID: <1216734685.3514.5.camel@localhost.localdomain> The next rawhide (whenever that may be) will have a new gnome-session that should fix many of the session management related issues that we've seen in rawhide lately. It has some pretty radical internal changes, though, so please give it a try and report any remaining or new issues. Thanks, Matthias From bnocera at redhat.com Fri Jul 25 00:13:09 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 25 Jul 2008 01:13:09 +0100 Subject: Freedesktop sound theming support Message-ID: <1216944789.3080.469.camel@cookie.hadess.net> Heya, In tomorrow's Rawhide (or maybe the day after) will be support for the Freedesktop sound theme spec. This means that libcanberra will be pulled in as a dependency. So please, test the control-center's new sound theming support (see the "Sounds" tab). And file bugs against any application that might be using libgnome or their own thing to play sounds (apps that come to mind are gnome-phone-manager, Gossip and gnome-power-manager). Cheers From kmaraas at broadpark.no Sun Jul 27 00:17:37 2008 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Sun, 27 Jul 2008 02:17:37 +0200 Subject: Unexpected shutdown... what? In-Reply-To: <1216330232.31373.64.camel@metroid.rdu.redhat.com> References: <1215697461.8454.1.camel@localhost.localdomain> <1215698027.3290.3.camel@localhost.localdomain> <1215949305.6232.3.camel@localhost.localdomain> <1216045634.3259.0.camel@localhost.localdomain> <1216330232.31373.64.camel@metroid.rdu.redhat.com> Message-ID: <1217117857.3147.0.camel@localhost.localdomain> to., 17.07.2008 kl. 17.30 -0400, skrev Will Woods: > On Mon, 2008-07-14 at 10:27 -0400, Matthias Clasen wrote: > > On Sun, 2008-07-13 at 13:41 +0200, Kjartan Maraas wrote: > > > to., 10.07.2008 kl. 09.53 -0400, skrev Matthias Clasen: > > > > On Thu, 2008-07-10 at 09:44 -0400, Jesse Keating wrote: > > > > > Every single time I log out of gnome or shut down / reboot from the > > > > > gnome menu a few of my apps act as if they were kill -9'd and throw up > > > > > recovery messages that frighten/confuse users. Why? Why can't we as we > > > > > log out/shut down 'cleanly' close these applications? Why must > > > > > everything be 'dirty' upon login? > > > > > > > > Session management is in a somewhat broken state right now. > > > > I've sent my emissaries to Guadec to sort things out... > > > > > > > Is this also the reason why I can't see the reboot and shut down buttons > > > when I choose System->Shut down? > > > > > > The dialog that opens just has Hibernate, Suspend and Cancel buttons. > > > > Yes, same reason. > > There's a bug filed about it: > https://bugzilla.redhat.com/show_bug.cgi?id=452639 > > Matthias, could you look at that bug and see if it's filed in the right > place (it's currently against gnome-panel), and (if possible) give an > update on the status? It's something I'd like to see fixed for > F10Alpha.. > It seems to work as expected for me now. Thanks. Cheers Kjartan From landonmkelsey at hotmail.com Thu Jul 31 16:13:10 2008 From: landonmkelsey at hotmail.com (landon kelsey) Date: Thu, 31 Jul 2008 11:13:10 -0500 Subject: Fedora 9 desktop problems Message-ID: I have the very latest F9 and KDE 4 via yum update Yes I will send KDE problems to KDE! If I can differentiate since day 1 and existing now on boot 1-0:1.0 unable to enumerate USB device on hub # 2 1-0:1.0 unable to enumerate USB device on hub # 4 1-0:1.0 unable to enumerate USB device on hub # 2 problem : computer hangs occasionally usually connected to popups from panel items. Sometimes I can clear the hangup by hitting keys ctrl-alt but usually I have to unplug/replug the flash memory drive. I have a card that connects all USB 2.0 devices since my built-in USB is 1.1 Once upon a time NTFS and VFAT flash memory drive were mounted via entries in fstab. Then they went auto. Now I must open NTFS and VFAT flash memory drive via dolphin to mount them or else nothing will be able to see them! When installing F9, I used gnome for a while and the icons for NTFS and VFAT flash memory drive were at the upper left. This is probably in the KDE realm. _________________________________________________________________ Use video conversation to talk face-to-face with Windows Live Messenger. http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_072008 -------------- next part -------------- An HTML attachment was scrubbed... URL: