On Sun, Aug 08, 2010 at 08:40:28PM +0300, Felipe Contreras wrote:I've used an N800, and I wasn't impressed; if anything, the fact that I have to worry about manually killing off applications when memory gets low, I actually thought it was incredibly sucky. It was a miniature, badly done laptop. Maybe the N900 is different, but the bigger question is what do you mean by "multi-tasking"? Definitions are critical here, which is why Paul was so careful in his definitions section of his document. Do you mean: * allowing multiple processes running at the same time? * allowing some applications to be able to update mail, play audio, upload location information so your friends know where you are? * allowing arbitrary applications that users can interact with simultaneously (which implies a window manager, the need to have the concept of window focus for keyboard input), etc? or something else? If you are using a GUI framework which is optimized for a single- application-focus-at-a-time UI that isn't GNOME or KDE, then that will require the applications to be written. However, that's not because of suspend-blockers. If you assume a GUI framework which is flexible enough --- maybe Qt falls into this category, maybe not --- for the rest of the applications, they don't need to *know* about suspend blockers, and they certainly do't have to be rewritten or modified specifically for suspend blockers. So if your argument is that applications that don't need bacground services (which you've admitted comprises majority of applicatios) need to be modified or written specifically to support suspend blockers, that's simply not true. They don't need to be modified at all. As far as whether they *should* require suspend blockers to be in the kernel to get power usage that is suitable for cell phone batteries, I would agree that in the ideal world, it would be nice if you could have applications that make the correct performance/battery utilization tradeoff for devices running on 800 mWh batteries, 94,000 mWh batteries, and while running on the AC mains. But I don't believe that it's likely to be true, and if you want to try to beat up on application writers one at a time to be power optimized --- as far as I'm concerned, that's an argument *for* suspend blockers, since I'm not big believer in plans that begin, "First, you command the tides of the sea to go back", King Canute style. :-) - Ted --
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object dir for .config |
git: | |
| Brian Downing | Re: Git in a Nutshell guide |
| John Benes | Re: master has some toys |
| Matthias Lederhofer | [PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree |
| Alexander Sulfrian | [RFC/PATCH] RE: git calls SSH_ASKPASS even if DISPLAY is not set |
| Junio C Hamano | Re: Rss produced by git is not valid xml? |
| Linux Kernel Mailing List | iSeries: fix section mismatch in iseries_veth |
| Linux Kernel Mailing List | ixbge: remove TX lock and redo TX accounting. |
| Linux Kernel Mailing List | ixgbe: fix several counter register errata |
| Linux Kernel Mailing List | b43: fix build with CONFIG_SSB_PCIHOST=n |
| Linux Kernel Mailing List | 9p: block-based virtio client |
