[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Boot poster challenge



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]