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. > > > People in bandwidth rich situations > Correct. > > > 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, or any other system with relatively slow "disk" I/O, or "slow" CPU. Yum isn't really the problem here, it's the rpms themselves, constantly doing ldconfigs, cache updates, tonnes of hardlinking, etc... and while people are working to correct some of this, the fact still remains that processing updates chews up system resources. > > 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, 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. > > 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. Just not me personally. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating)
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
