On Tue, 2004-11-16 at 18:43 -0500, Dave Jones wrote: > On Tue, Nov 16, 2004 at 06:29:40PM -0500, Alan Cox wrote: > > > Utterly. On multihead boxes I've seen it take 30% of the total CPU time > > and 20% of the network bandwidth. Its eeeeevil because it should be a > > service daemon so it runs *ONCE* and it should chat over dbus or something > > to the display which -should-not-flash- - it's very bad UI design (movement > > out of the user focus area is distracting) and sucks resources. > > It also gets 'stuck' sometimes, making the user believe that everything > is up to date, whilst running up2date -l, or yum will find packages > that need updating. I've also seen it claim updates are available > that running up2date on the command line can't find. *boggle* > > The whole thing needs a bullet in its head imo. > > I never thought I'd say it, but after having recently bought a > mac for my wife, Apple did something right. They have something > (possibly a cron job) that looks for updates at a user specified > interval, and if nothing is found, it does nothing. You don't even > know it checked. If it does find something, it pops up a dialog. > None of this flashing red bubble nonsense. The whole time you're > blissfully unaware of this going on, which is a big win > memory footprint wise. I've had some ideas for that, but keeping the memory footprint down might be a bit taxing. thought is easy enough, though. have the nightly cron job generate an rss feed of the available updates. (yum generate-rss updates) then have the applet just look for and read the rss file. -sv
