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; we should be able to speed this up by taking advantage of additional cores (and hyperthreading) on the system, for example. Another option might be not to bother recompressing the RPMs but instead just install an uncompressed RPM (and possibly recompress it out of band if we needed to keep it in the cache).
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
