On Oct 18, 2014 5:00 PM, "Nico Kadel-Garcia" <nkadel@xxxxxxxxx> wrote:
>
> On Thu, Oct 16, 2014 at 11:40 PM, Gerald B. Cox <gbcox@xxxxxx> wrote:
> > My comment was not meant to be argumentative, but rather tongue-in-cheek.
> > However, I do believe when changing a default, it isn't about what is
> > convenient for me. It's about what is best for the entire community and
> > what are the real world ramifications. I'm not buying the "let's change the
> > default because high bandwidth is pervasive argument".
> >
> > I'll go out on a limb here and suggest:
> >
> > 1. Most people who can afford to pay the monthly recurring cost for a high
> > speed bandwidth connection have multi-core machines.
> > 2. People who are running Fedora on multiple machines possess the skill set
> > to easily change the default and turn Presto off if they wish.
>
> You left out some but related issues.
>
> 3) People who have a lot of hosts and high bandwidth, high speed
> local deployment requirements can, and do, set up an internal Fedora
> mirror with much lower bandwidth costs. This reduces the tangible
> benefits of deltarpms significantly. This is combined with my direct
> observation that working from plain rpms is much faster and more
> reliable. Re-assembly from deltarpms is computationally expensive and
> thus expensive for large numbers of yum clients. It sounds like a
> great idea at first glance, but it profoundly and unpredicatably
> increases the disk space and bandwidth needed for mirrors themselves
> at a relatively small benefit in download bandwidth. The great example
> of difficult to "delta RPM's" sems to be libreoffice. Between the
> compressed and distinct binaries for the war files, and the deltarpm
> process itself, they save very little bandwidth for many of the
> builkies projects.
>
> 4) The much, much larger source of wasted bandwidth and resources is
> the yum repodata. That's 50 Meg, every time the repodata expires or is
> updated, even if there are no actual RPM updates. And for systems that
> need frequent updates and refreshes to ensure the latest packages,
> it's consumed *every single time* you flush the metadata.
>
> > What about the repositories and mirrors? Do they all have unlimited, cheap
> > bandwidth?
>
> No one does. But in my direct observation, deltarpms are a
> theoretically clever attempt to solve the wrong problem, an attempt
> that requires massive *extra* diskspace and resources for the mirror
> sites that doesn't address the more consistent and demonstrable
> problem.
>
> There are environments where bandwidth limits are so great that even
> the bare RPM downloads are vulnerable to interruption, and the
> marginal improvement of the deltarpm would be noticeable. But I've not
> seen such an environment in roughly 10 years, and it was usually to
> some bad network hardware or local misconfiguration.
> --
Network operators will experience a real, tangible cost increase from turning off deltarpms. End users with metered bandwidth - off the cuff, I'd guess hundreds of thousands of current users and billions of prospective users - will experience a real financial impact from the 'loss' of this feature.
Now, I realize everyone can turn this on, and everyone can turn it off. Changing the default option doesn't take away the feature. Those with metered connections will probably, eventually, discover they can turn deltarpms on. After the first bill arrives, or the second. These are likely to be people with limited financial resources, using computers that you couldn't pay me to work on these days. We're keeping the entire 32bit architecture alive for them; in contrast to that, the infrastructure burden of deltarpms is slight. Even so, we continue to welcome this demographic to use and participate in Fedora.
Faster update transactions are good, but anyone that's concerned about the *financial impact* of consuming extra CPU cycles ( as in Nico's case #3) is very likely to be employing a competent administrator (like Nico) that should know how and why to flip the switch. Nobody wants to take this option away, and I doubt it would even be possible.
--Pete
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
