Re: No more deltarpms by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux