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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
