Lack of update information

[Ralf Corsepius]

Jesse Keating wrote:
> On Tue, 2009-01-27 at 03:11 +0100, Ralf Corsepius wrote:
>> Jesse Keating wrote:
>>> On Tue, 2009-01-27 at 01:22 +0100, Ralf Corsepius wrote:
>>>>  The problem with this: Users don't notice the cases in which upgrades 
>>>> "simply work" - They only notice the case, something already has gone wrong.
>>> Many users notice a plethora of updates for unknown reasons that chew up
>>> their bandwidth, cpu, and disk time while they're just trying to get
>>> work done.  So much so that many opt out of applying updates at all,
>>> because there are so many of them, which hurts our abilities to deliver
>>> security updates.
>> These problems do not originate from the number of upgrades/update, they 
>> originate from the _size_ of updates few packages introduce.
> 
> Size is in direct correlation to number.
With all due respect, Mr. Keating, this is non-sense.

One update to openoffice/evolution/kde/gnome/kernel or some game's data 
outweighs many other packages.

>>> and with new expensive fast hardware
>>> may not see a problem. 
>> Well, I would label this an urban legend - Updating recent Fedoras using 
>> yum has not been much of a performance problem, even on slower and older 
>> HW (e.g. a 1GHz i686/512MB)
>>
>> Admitted, on an 64MB/166MHz i586 w/Fedora 10 yum updates tend to be 
>> "really slow".
> 
> Try doing updates on a netbook, 
I own one - Typical "yum update" times are in the order of "very few" 
minutes at average.

Example from a couple minutes ago (comprising kernel/kernel-devel, 
PackageKit, selinux-policy and some rpmfusion updates - 20 packages in 
total; Using local (fast) mirrors):

# cat /proc/cpuinfo
..
model name	: Intel(R) Atom(TM) CPU N270   @ 1.60GHz
..

# time yum -y update
...
real	7m48.916s
user	4m50.155s
sys	0m57.314s

Not fast, but hardly a serious problem.

On an i586, the times requires for yum updates are much higher 
(typically hours), times on old i686's are in the order of several 10 
minutes.

> or any other system with relatively slow
> "disk" I/O, or "slow" CPU.

The cases I mention are real - I do own such machines.

On these, the real yum update related problems are bandwidth and 
disk-space requirements (yum-caches).

PackageKit's GUI and parsing activities adds further (quite measurable) 
requirements on CPU-power and RAM.

>  Yum isn't really the problem here, it's the
> rpms themselves, constantly doing ldconfigs, cache updates, tonnes of
> hardlinking, etc... 

 From what I experience, SELinux policy updates are by far means the 
most resource intense/most time consuming part of updating.

>> However, wrt. to bandwidth, I see another problem: Your strategy of 
>> pushing updates in "big batches", instead of "small chunks".
>>
>> This makes a significant difference to users with limited bandwidth. 
>> While they could easily poll "small chunks", e.g. once a day (blocking 
>> their network for, e.g. 1 hour), the current strategy would block they 
>> network for very much longer (e.g. 7 hours).
> 
> If I were to push updates once a day, the mirrors would be in shambles,
I can't prove nor counter-prove this claim, but I doubt that this would 
make much of a difference.

> constantly trying to pick up the new content and users would have a
> terrible experience.  Pushing updates faster doesn't magically make the
> number of updates get smaller.

On the end-user's side it makes a substantial difference if whether one
of your "big pushes" blocks a machine/network for the whole day,
or whether a "yum update" finishes during a "work break".

>> Another aspect related to bandwidth: Revisiting
>> * the sizes of rpms (e.g. different payload compressors).
>> * differential updates/rpms.
>>
>> Seems to me as if these once "hot topics" have dropped off the Fedora 
>> radar, in favor of "strangling/nagging the distro's contributors".
>>
>> Ralf
>>
> 
> People are working on both of the above issues.
Really? I doubt your claim. At least I am not aware of any activities in 
RH's rpm to change rpm's payload rsp. to perform measurements on the 
impact of using modern compressors on rpm-payloads.


Ralf