On Mon, Oct 6, 2014 at 3:07 PM, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > > > On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote: >> On 6 October 2014 09:41, Rahul Sundaram <metherid@xxxxxxxxx> wrote: >> > Hi >> > >> > One of the long standing features that were enabled by default in yum is >> > support for delta rpms. dnf developers have disabled this and I think this >> > change deserves a broader discussion >> > >> > https://bugzilla.redhat.com/show_bug.cgi?id=1148208 >> > >> >> "I have an internet flatrate at 150 mbs, and downloading the full rpms >> is ALOT faster than the the work that the delta rpms requires." >> >> Wow. Good to see normal users are taken into account. The main >> argument from a distro point of view is reducing load on servers, but >> I don't know many people on 150Mbs either. Heck, I've just tested my >> work janet connection and that's <100Mbs in our office. At home 8Mbps >> is a good day. (I'm assuming mbs is a typo for Mbps and not milli bit >> seconds, where the very slow transfer speed declines exponentially as >> the connection progresses.) > > > The deltarpms were meant to serve two purposes > > 1) (lesser) Address the needs of users in developing countries (where > Fedora is fairly popular) and bandwidth concerns are very considerable. > Many of these users have connections that are either metered or > extremely slow, so deltarpms provides a way to get the data to them more > economically. This of course can be handled with a non-default option, > so we can talk about making that more discoverable if we disable them by > default. > > 2) (Major) Deltarpms significantly (Kevin, can you comment with > numbers?) reduces the load on the Fedora update servers and mirrors, > thereby reducing hosting costs as well as increasing the efficiency of > the available bandwidth (since smaller downloads mean you will be tying > up the line for a shorter amount of time). > > It would be nice to see if we can find ways to improve the performance > of the deltarpm reconstruction instead. Much of the time is spent on > compression/decompression tasks which *should* be massively parallel s/massively parallel/not done at all/ ... but we had this discussion each time this comes up. There is no point in compressing something just to uncompress it a few minutes later. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
